- ksk-rollover - lists.icann.org

A DNSSEC issue during KSK rollover
by Davey Song(宋林健) Oct. 26, 2016

Oct. 26, 2016

Hi KSK rollover team, For your information, there is a article I put down to describe the issue we found during Yeti KSK rollover. Hope it helps. http://yeti-dns.org/yeti/blog/2016/10/26/A-DNSSEC-issue-during-Yeti-KSK-roll over.html Best regards, Davey

1 0

Root zone KSK rollover technical update (2016-09-19)
by Matt Larson Sept. 27, 2016

Sept. 27, 2016

Dear folks interested in the root zone KSK roll, Recently ICANN published the first in what will be an occasional series of technical updates on the progress of the Root Zone KSK Rollover project. The post is entitled "First step of 2017 KSK Rollover External Test Plan completed<https://www.icann.org/resources/pages/ksk-rollover-technical-updates-2016-0…>". The next milestone in the project is KSK Ceremony 27<https://www.iana.org/dnssec/ceremonies/27> on October 27, 2016, when KSK-2017, the next KSK, will be created. More details on the schedule and project milestones are available on the project web page<https://www.icann.org/resources/pages/ksk-rollover> and in the operational plans<https://www.icann.org/resources/pages/ksk-rollover/#operational-plans> linked to on that page. As always, please let us know if you have any questions. Matt -- Matt Larson VP of Research, Office of the CTO, ICANN +1 240 459-9562 (mobile)

1 0

Fwd: RFC 7958 on DNSSEC Trust Anchor Publication for the Root Zone
by Jakob Schlyter Sept. 1, 2016

Sept. 1, 2016

Forwarded message: > From: rfc-editor(a)rfc-editor.org > To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org > Cc: drafts-update-ref(a)iana.org, rfc-editor(a)rfc-editor.org > Subject: RFC 7958 on DNSSEC Trust Anchor Publication for the Root Zone > Date: Wed, 31 Aug 2016 18:38:56 -0700 (PDT) > > A new Request for Comments is now available in online RFC libraries. > > > RFC 7958 > > Title: DNSSEC Trust Anchor Publication for > the Root Zone > Author: J. Abley, J. Schlyter, > G. Bailey, P. Hoffman > Status: Informational > Stream: Independent > Date: August 2016 > Mailbox: jabley(a)dyn.com, > jakob(a)kirei.se, > guillaumebailey(a)outlook.com, > paul.hoffman(a)icann.org > Pages: 14 > Characters: 26072 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-jabley-dnssec-trust-anchor-16.txt > > URL: https://www.rfc-editor.org/info/rfc7958 > > DOI: http://dx.doi.org/10.17487/RFC7958 > > The root zone of the Domain Name System (DNS) has been > cryptographically signed using DNS Security Extensions (DNSSEC). > > In order to obtain secure answers from the root zone of the DNS using > DNSSEC, a client must configure a suitable trust anchor. This > document describes the format and publication mechanisms IANA has > used to distribute the DNSSEC trust anchors. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > >

1 0

The risk of miscommunication
by Stephane Bortzmeyer Aug. 2, 2016

Aug. 2, 2016

The Yeti test bed is currently trying a second KSK rollover <https://github.com/shane-kerr/Yeti-Project/blob/experiment-kroll/doc/Experi…> and there was a funny incident. A resolver admin, misinterpreting the instructions, updated manually his config with the new key, despite the fact it was still in AddPend state and not used for signing. Since people have a tendency to make mistakes, I suggest to pay extreme attention to the communication and documentation, when explaining sysadmins what to do.

5 5

Plan documents for root KSK roll project now available
by Matt Larson July 26, 2016

July 26, 2016

On Friday, July 22, in the interests of transparency and to notify the DNS operational community, ICANN posted plans<https://www.icann.org/resources/pages/ksk-rollover#operational-plans> to roll the root zone key signing key (KSK). These plans were developed by the Root Zone Management Partners: ICANN in its role as the IANA Functions Operator, Verisign acting as the Root Zone Maintainer, and the U.S. Department of Commerce's National Telecommunications and Information Administration (NTIA) as the Root Zone Administrator. The plans incorporate the March 2016 recommendations<https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf> of the Root Zone KSK Rollover Design Team, after it sought and considered public comment<https://www.icann.org/news/announcement-2013-03-08-en> on a proposed rollover process. The process of creating a new key, using it to sign the root DNSKEY RRset and securely destroying the old key will start in Q4 2016 and last until Q3 2016, though the portions resulting in visible changes in DNS occur between Q3 2016 and Q1 2017. The important milestones in the project are: - October 26, 2016: The new KSK is generated in ICANN's U.S. East Coast key management facility (KMF). - February, 2017: The new KSK is copied to ICANN's U.S. West Coast KMF and is considered operationally ready, and ICANN publishes the new key at https://data.iana.org/root-anchors/root-anchors.xml. (The exact date is dependent on the timing of the Q1 2017 key ceremony, which has not yet been scheduled.) - July 11, 2017: The new KSK appears in the root DNSKEY RRset for the first time. - October 11, 2017: The new KSK signs the root DNSKEY RRset (and the old KSK no longer signs). This date is the actual KSK rollover. - January 11, 2018: The old KSK is published as revoked (per RFC 5011, "Automated Updates of DNS Security"). What you need to do If you operate any software performing DNSSEC validation (such as a security-aware recursive name server) that implements the RFC 5011 automated trust anchor update protocol and this functionality is enabled, you have no action: your software will notice the new KSK (authenticated by the old KSK) and update its trust anchor store accordingly. If you operate any software performing DNSSEC validation that does not implement RFC 5011 or if you don't use the RFC 5011 protocol, you will need to update your software's trust anchor configuration manually to add the new KSK before October 11, 2017. You can obtain the new KSK in February, 2017, using one of the methods described in the "Trust Anchor Publication" section of 2017 KSK Rollover Operational Implementation Plan<https://www.icann.org/en/system/files/files/ksk-rollover-operational-implem…> (one of the aforementioned recently published plans). If you write, package or distribute software that performs DNSSEC validation and you hard code the root KSK (e.g., in code or configuration files), you should update your software with the new KSK when it becomes available in February, 2017. Staying informed ICANN will post occasional notices to various operational forums to keep the community informed of this project's progress, but we strongly suggest that anyone with an interest subscribe to the root KSK rollover mailing list<https://mm.icann.org/mailman/listinfo/ksk-rollover> operated by ICANN (ksk-rollover(a)icann.org<mailto:ksk-rollover@icann.org>). The list is extremely low volume. The ICANN staff supporting and implementing the root KSK rollover project welcome your questions and comments: please direct them to the ksk-rollover(a)icann.org<mailto:ksk-rollover@icann.org> list. Matt -- Matt Larson VP of Research Office of the CTO, ICANN

1 1

Thoughts on 5011 compliance detection.
by Michael StJohns July 25, 2016

July 25, 2016

Hi - A discussion on 5011 with Wes Hardaker got me thinking about ways of detecting whether or not a client querying the root has 5011 support. 5011 has very definite timing recommendations for queries (section 2.3). I'm wondering if looking at the data sets for queries to the root and the intervals between those queries might reveal the majority of 5011 capable clients? So: 1. Determine the queryInterval and retryTime based on the formulas in 2.3 for the current DNSKEY RRSet. 2. Grab all the queries from all of the root servers that satisfy the characteristic that they were for the DNSKEY RRSet and associated RRSig only along with when they were received. 3. Consolidate them somewhere. 4. Sort and group by query address. 5. Determine the intervals between subsequent queries for each group. 6. Separate the intervals into retryTime periods, queryInterval time periods and non-compliant periods (e.g. everything not within 5% either way of the values calculated in step 1). 7. Score each client based on the proportions of query and retry vs non-compliant periods. 8. Set aside the data sets showing > 20% non-compliance for later analysis. 9. Change one or more of the signature or TTL times in a way that causes a change in the query and retry intervals. 10. Repeat 1-8 again and correlate the results against the first run looking for query patterns that indicate that a client has adapted to the query interval. This may or may not be possible to accomplish given the various demands on Verisign and ICANN, but it might actually glean real data. Its also possible that the Active refresh process is just using data gleaned from normal queries in which case this pattern won't be seen. AFAICT, the current values of original TTL are 2 days, and the value of RRSigExpirationInterval is 14 days. So queryInterval is MAX (1 hour, Min(15 day, 1day, 7 day)) or 1 day. Retry interval is MAX (1 hr, min (1 day, 4.8h, 33.6h)) or 4.8 hours. So finding clients that mostly query the DNSKEY RRSet directly either on a 4.8 hour or 1 day basis might reveal some 5011 clients. Mike

1 0

Fwd: Invitation to "Upcoming ZSK and KSK Changes to the Root Zone" on Tuesday, 19 June, in Berlin
by Matt Larson July 9, 2016

July 9, 2016

Hello KSK rollover folks, Please see the message below for information about an upcoming presentation on the root KSK roll during the IETF in Berlin. Matt -- Matt Larson VP of Research Office of the CTO, ICANN Begin forwarded message: From: Matt Larson <matt.larson(a)icann.org<mailto:matt.larson@icann.org>> Subject: Invitation to "Upcoming ZSK and KSK Changes to the Root Zone" on Tuesday, 19 June, in Berlin Date: July 8, 2016 at 3:45:03 PM EDT To: <96attendees(a)ietf.org<mailto:96attendees@ietf.org>> Dear IETF colleagues, I'd like to invite anyone interested in DNSSEC in the root zone to a session on "Upcoming ZSK and KSK Changes to the Root Zone" on Tuesday, 19 June, from 1230-1345 in the Bellevue Room in the InterContinental Hotel. ICANN and Verisign, as IANA Functions Operator and Root Zone Manager, respectively, are cooperating on two projects that are changing aspects of DNSSEC operation in the root zone: the root zone ZSK is increasing in size from 1024 bits to 2048 bits<http://blogs.verisign.com/blog/entry/increasing_the_strength_of_the> and the root zone KSK will be changing<https://www.icann.org/resources/pages/ksk-rollover>. Duane Wessels from Verisign and I will talk about the plans and answer any questions. Because of the critical nature of the root zone and the significance of these changes, Verisign and ICANN are making a number of presentations to increase awareness. We approached the IAB about a presentation in Berlin and they suggested this lunchtime slot. We'd like to thank the IAB and the Secretariat for graciously offering a room. Thanks and see you in Berlin, Matt -- Matt Larson VP of Research Office of the CTO, ICANN

1 0

[ksk-change] KSK rollover webpage
by David Conrad May 10, 2016

May 10, 2016

Hi, Just FYI, but we've created a web page related to the KSK Rollover: https://www.icann.org/resources/pages/ksk-rollover We'll be posting more information and pointers here soon. Regards, -drc

1 0

[ksk-change] A document related to Root Zone KSK rollover
by Edward Lewis July 22, 2015

July 22, 2015

The attached is self-describing. But to help you decide whether to open it...there is a Design Team helping plan the root zone KSK key roll. A draft document is in production, draft meaning that is will go to an ICANN Public Comment before finalization. But before we get to that, perhaps this audience will want to have a look. Ed

1 0

[ksk-change] How to tell which trust anchors are present at a DNS resolver.
by Michael StJohns March 26, 2015

March 26, 2015

One of the discussions we've been having about 5011 roll overs is that there's no way to tell whether or not they are "taking" because there's no way to check the resolvers externally. I was looking at various possibilities including locally significant RRs that could be queried to , but nothing clicked. After a beer with Scott Rose - we came up with the following convention: Querying a server with QNAME="." and QTYPE="DS" and with no recursion, gets you a set of DS records that represent the trust anchors for that server for the root. This would have to be implemented, but given that I think it may take 2 years to get the rollover done, that may not be a problem. Comments on this approach? (Note comments of "this won't work because its too late" are understood and ignored). What we;re looking for are comments on whether the convention has bad side effects or would be difficult to implement correctly. Mike

4 4