- ksk-rollover - lists.icann.org

Update on root KSK roll project for December 2017
by Matt Larson Dec. 18, 2017

Dec. 18, 2017

Dear colleagues, I just posted an update on the root KSK roll project at https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project. The text is reproduced below for your convenience and please let me offer the customary apology if you receive duplicate postings of this message on multiple mailing lists. Matt -- Matt Larson <matt.larson(a)icann.org> VP of Research, Office of the CTO, ICANN The ICANN org is today announcing that it will not roll the root zone KSK in the first quarter of 2018. We have decided that we do not yet have enough information to set a specific date for the rollover. We want to make clear, however, that the ICANN org is committed to rolling the root zone KSK and we will continue to discuss this important process with the community, gather their feedback and give all interested parties advance notice of at least one calendar quarter when we set the date for the rollover. Furthermore, we are soliciting input from the community to help determine, if possible, appropriate objective criteria to measure the possible negative impact of the root KSK rollover on Internet users, and acceptable values for those criteria before a rollover. This is in accordance with the bottom-up, multi-stakeholder model that has been so successful for ICANN policy development. On 27 September 2017, the ICANN org announced it was postponing the root zone KSK rollover for at least one quarter, leaving open the possibility the root KSK rollover might occur in the first quarter of 2018. We have since realized that our analysis and preparation will require additional time. In a previous post, we described our analysis of recursive resolver trust anchor configuration information reported using the protocol defined in RFC 8145, Signaling Trust Anchor Knowledge in DNS SecurityExtensions (DNSSEC). Our analysis revealed that about 4% of the approximately 12,000 DNSSEC-validating resolvers reporting during the month of September 2017 were configured with only KSK-2010 (the shorthand for the current root KSK) and would have been unable to resolve DNS queries after the rollover occurred. The ICANN org's decision to postpone the rollover was based on the concern that we did not understand why those resolvers were not properly configured, and we needed time to investigate. Since then, we have attempted to contact the operators of 500 addresses that had reported a resolver configuration with only KSK-2010 instead of the correct configuration of both KSK-2010 and the new KSK, KSK-2017. Ideally, that investigation would have revealed a set of clear causes for the improper configuration, allowing further communication and actions to be targeted at addressing those specific issues. But in the end, the analysis was not as conclusive as we would have hoped. In our initial attempt, we received a response from operators of approximately 20% of the 500 addresses. Of those addresses whose operators we could contact, 60% came from address ranges known to host devices with dynamic addresses, such as routers of home broadband users and ephemeral virtual machines, making these resolvers extremely difficult (if not impossible) to track down. About 25% of the addresses corresponded to a resolver forwarding on behalf of another resolver that was reporting only KSK-2010. Since the address of the device reporting the incorrect configuration was not the actual source resolver, it is extremely difficult (if not impossible) to identify the true source address of the resolver that was reporting only KSK-2010. To proceed with the root KSK rollover, the ICANN org must have confidence that the rollover will not have an unacceptable negative impact on Internet users. The challenge we have encountered since we began to analyze the RFC 8145 trust anchor configuration reports from resolvers is assessing the impact on users. We can make a number of assumptions: for example, it is unlikely that a recursive resolver running at a dynamic address could support a large number of users since it does not offer a stable address for any devices to send queries to for resolution. But ultimately, determining potential user impact based on the data available to us is difficult and we are therefore soliciting the community's input. Input and discussion on acceptable criteria for proceeding with the KSK roll will take place on an existing email list that is already being used for discussion of the root KSK rollover. We encourage anyone interested in contributing to join the mailing list by visiting https://mm.icann.org/mailman/listinfo/ksk-rollover. The ICANN org will monitor this mailing list and beginning on 15 January 2018, we will develop a draft plan for proceeding with the root KSK roll based on the input received and discussion on the mailing list. The plan will be published by 31 January 2018 and undergo a formal ICANN public comment process to gather further input. We will hold a session at ICANN61 in San Juan, Puerto Rico, to discuss the plan and hear from the community in person. Our intent is to have a revised plan available for community review and public comment prior to ICANN62 in Panama City, Panama, with a final plan published soon thereafter. Throughout the process we'll continue to keep the community updated on the root KSK rollover project's progress.

1 0

Webinar: The KSK Rollover Delay and Next Steps
by Matt Larson Oct. 5, 2017

Oct. 5, 2017

ICANN will be holding a webinar on the root KSK rollover delay and next steps on October 11. Please find the details, including how to join, in the announcement at https://www.icann.org/news/announcement-2017-10-04-en. Matt -- Matt Larson, VP of Research ICANN Office of the CTO

1 0

Fw: [dns-operations] Request for prior announcement of Root KSK Rollover critical time
by Yoshiro YONEYA Sept. 14, 2017

Sept. 14, 2017

My apologies for muliple post. Begin forwarded message: Date: Thu, 14 Sep 2017 17:20:25 +0900 From: Yoshiro YONEYA <yoshiro.yoneya(a)jprs.co.jp> To: dns-operations(a)dns-oarc.net Subject: [dns-operations] Request for prior announcement of Root KSK Rollover critical time Hi all, Someone from Verisign or ICANN please let us know mostly exact time of the following two events in advance. (1) DNSKEY size increase on Sep 19th (2) new KSK sign Oct 11th Unofficially I heard that it would be 16:00 UTC, but I (and perhaps many of operators) need official announcement, hopefully by this friday (Sep 15th). Regards, -- Yoshiro YONEYA <yoshiro.yoneya(a)jprs.co.jp> _______________________________________________ dns-operations mailing list dns-operations(a)lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-operations mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-operations

2 1

Observation on Large response issue during Yeti KSK rollover
by Davey Song(宋林健) Aug. 21, 2017

Aug. 21, 2017

Hi ICANN KSK rollover team, For your information, I have an observation on large response impacts during Yeti KSK rollover. Please check the article. http://yeti-dns.org/yeti/blog/2017/08/02/large-packet-impact-during-yeti-ksk -rollover.html Best regards, Davey

6 9

new root trust anchor confirmation
by Daisuke HIGASHI Aug. 17, 2017

Aug. 17, 2017

Is there any method to confirm that my validator has accepted new root KSK trust anchor and can actually validates with new TA before 11 Oct? Any test records signed with _only_ new KSK in root zone? Regards, -- Daisuke Higashi

9 13

Automated Updates (aka RFC 5011) add-hold for the new root zone KSK expires soon
by Edward Lewis Aug. 11, 2017

Aug. 11, 2017

Looking at my records, the new KSK appeared between 2017-07-11@1305UTC and 2017-07-11@1405UTC. (I run some probes at 5 minutes after the hour.) "30 Days later" means 10 August (not 11 August!). We are less than 24 hours away from that as I write this message (about 20 hours now).

7 7

15 days into the add-hold for KSK-2017
by Edward Lewis July 29, 2017

July 29, 2017

Wanted to "mark the occasion" and ask if there are any further concerns? RFC-5011 following servers ought to be about halfway to trusting KSK-2017 about this day, with the add-hold expiring around August 11, give or take time zones and when probing happened. That's halfway to "trusting" the key. There's still 2.5 more months (October 11) until signatures by KSK-2017 appear.

4 5

Windows Server 2016 Accelerated DNSSEC Root Rollover HowTo
by Richard Lamb June 26, 2017

June 26, 2017

Given the Infoblox note on this list and recently being (pleasantly) surprised by my students at the number of Windows DNS resolver installations out there considering DNSSEC, I felt the need to run through the exercise of stress testing Win Server 2016 DNS against accelerated RFC5011 rollover https://icksk.dnssek.info/fauxroot.html (did Win Server 2012 R2 a while back). The platform follows the root key rollover steps in a continuous accelerated fashion and has been operation since 2015 testing against various resolvers specially configured to work with accelerated RFC5011. RESULT: I saw no problems with Windows Server 2016 out of the box. The DNS server properly tracked continual accelerated root key rolls (ever 27 minutes) with no validation failures and keys recorded in C:\windows\system32\dns\rfc5011.csv. I know this should not be new info but just call me cautious. The steps I took are at https://icksk.dnssek.info/w2k16howto.html if you want to replicate. Hope it helps. -Rick

2 2

Infoblox does not support RFC5011
by Lagerholm, Stephan June 21, 2017

June 21, 2017

Hi , About a week or so ago I got a notification email from Infoblox that they do not support RFC5011. They are referring to a Knowledge base article on their site on how to enable the new key in the products, see below. I know that Infoblox is a common product in the marketplace. It worries me that some of their customers will not get/read/take action on the notification resulting in that resolution will start to fail on Oct 11th. Especially the US Govt. sector worries me as they have various mandates to implement DNSSEC but (based on my own experience and some speculation) sometimes lacks the skills and long term vision to maintain it properly. Is there any additional outreach or action that can be taken to make sure that the KSK rollover don't break Infoblox customers? Dear Customer, In 2016 the Internet Corporation for Assigned Names and Numbers (ICANN) announced<http://app.e.infoblox.com/e/er?s=953&lid=5086&elqTrackId=EDFAFB40787A8022D6…> a two-year execution plan for rolling the Root Zone Domain Name System Security Extensions (DNSSEC) KSK key. According to that plan, on October 11, 2017, a new KSK key will be used to sign the Root Zone DNSKEY resource record set (the actual rollover event). This requires an action on your part. Rolling the KSK key means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root's "trust anchor." The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet's DNS. Maintaining an up-to-date KSK is essential to ensuring DNSSEC-validating DNS resolvers continue to function following the rollover. Failure to have the current root zone KSK will mean that DNSSEC-validating DNS resolvers will be unable to resolve any DNS queries which would lead to an outage. Currently Infoblox NIOS does not support "Automated Updates of DNS Security (DNSSEC) Trust Anchors" feature (RFC-5011) that automatically updates the key. Therefore, the new Root Zone KSK key must be manually updated on all DNSSEC validation enabled servers. Please refer to Infoblox Support KB # 5729<https://support.infoblox.com/app/utils/login_form/redirect/answers%252Fdeta…> for the ICANN plan details and steps to update the new Root Zone KSK key to prevent potential DNS resolution issues. Sincerely, Infoblox Support Team

2 1

The timing of publication of signatures by new KSK
by Ólafur Guðmundsson June 8, 2017

June 8, 2017

Dear Icann and Verisign, It is real important for Resolver operators to know when this happens as the publication time starts the clock on when validation failures begin. About 48 after last root server starts advertising the new DNSKEY closes the window of when last resolvers will start returning errors. Thus I request that ICANN + Verisign commit to publish the DNSKEY set signed by the new KSK on October 11'th at 12:00 UTC as that is the only time it is October 11'th everywhere in the world. This way we can know that all errors will be visible before 13:00 UTC on Oct 13'th, as over 99% of root servers load up new zone in less than an hour (I hope) Olafur

2 1