People involved with DNS security no longer have to be focused on October 11. News broke yesterday that ICANN has decided to postpone the Root KSK Rollover to an unspecified future date.
To be clear:
The Root KSK Rollover will NOT happen on October 11, 2017.
ICANN’s announcement states the the KSK rollover is being delayed…
…because some recently obtained data shows that a significant number of resolvers used by Internet Service Providers (ISPs) and Network Operators are not yet ready for the Key Rollover. The availability of this new data is due to a very recent DNS protocol feature that adds the ability for a resolver to report back to the root servers which keys it has configured.
Getting More Information
Discussion on the public DNSSEC-coord mailing list indicates more info may be available in a talk Duane Wessels is giving at the DNS-OARC meeting tomorrow (Friday, September 29). The abstract of his session is:
A Look at RFC 8145 Trust Anchor Signaling for the 2017 KSK Rollover
RFC 8145 (“Signaling Trust Anchor Knowledge”) was published in April 2017. This RFC describes how recursive name servers can signal, to authoritative servers, the trust anchors that they have configured for Domain Name System Security Extensions (DNSSEC) validation. Shortly after its publication, both Unbound and BIND implemented the specification. As organizations begin to deploy the new software versions, some of this “key tag data” is now appearing in queries to the root name servers.
This is useful data for Key Signing Key (KSK) rollovers, and especially for the root. Since the feature is very new, the number of recursive name servers providing data is not as significant as one might like for the upcoming root KSK rollover. Even so, it will be interesting to look at the data. By examining this data we can understand whether or not the technique works and hopefully inspire further adoption in advance of future KSK rollovers.
If you, like me, will not be in San Jose for this session, there will be a webcast / live stream. The link should be available tomorrow morning on the DNS-OARC event page. Or you can follow the #oarc27 hashtag or @dnsoarc onTwitter.
Per the OARC 27 timetable, Duane’s talk begins at 9:40am PDT (UTC-7). (Side note: for those involved with DNS, there are many other excellent sessions on the timetable!)
Apparently whatever data ICANN received through this research convinced them that not enough ISPs were ready to go with the new KSK and so a postponement was necessary.
I do understand why ICANN would step back and delay the KSK roll. If there are significant sections of the Internet that will experience issues with resolving DNSSEC-signed domains on October 11, it is prudent to wait to assess the data and potentially reach out to affected ISPs and other network operators. Particularly when, as we noted in our State of DNSSEC Deployment 2016 report last year, the number of domains signed with DNSSEC continues to grow around the world.
I look forward to working with ICANN and the rest of the DNSSEC community to set a new date. As I wrote (along with my colleague Andrei Robachevsky) in our comments back in April 2013, we believe that the Root KSK should be rolled soon – and rolled often – so that we gain operational experience and make Root KSK rollovers just a standard part of operations. (Note: our CITO Olaf Kolkman submitted similar comments, although at the time he was with NLnet Labs.)
Updating the DNS infrastructure is hard
The challenge ICANN faces is that updating the global DNS infrastructure is hard to do. The reality is that DNS resolvers and servers are massively DE-centralized and controlled by millions of individual people. You probably have one or more DNS resolvers in your home in your WiFi router and other devices.
The success of DNS is that generally it “just works” – and so IT teams often set up DNS servers and then don’t pay much attention to them. At a talk I gave yesterday to about 180 security professionals at the ISC2 Security Congress in Austin, TX, I asked how many people had updated the software on their DNS resolvers within the past year – only a few hands were raised.
All of the latest versions of the major DNS resolvers support the new Root KSK. Recent versions all generally support the automated rollover mechanism (RFC 5011). But… people need to upgrade.
And in the example of a home WiFi router, the vendor typically needs to upgrade the software, then the service provider has to push that out to devices… which can all take a while.
A group of us looking to expand the use of elliptic curve cryptography in DNSSEC wrote an Internet Draft recording our observations on deploying new crypto algorithms. Updating the root KSK as a trust anchor faces a similar set of issues – although a bit easier because the focus is primarily on all the DNS resolvers performing DNSSEC validation.
The critical point is – upgrading the global DNS infrastructure can take some time. ICANN and members and of the DNSSEC community (including us here at the Internet Society) have been working on this for several years now, but clearly the new data indicates there is still work to do.
The good news is that companies now have more time to ensure that their systems will work with the new key. The new Root KSK is published in the global DNS, so that step has at least been done. More information is available on ICANN’s site:
I would recommend two specific pages:
- Checking the Current Trust Anchors in DNS Validating Resolvers – instructions for how to check IF your resolver is performing DNSSEC validation, and, if so, how to ensure it is updated for the new key.
- Automated Trust Anchor Update Testbed– a system you can use to test if your resolvers will automatically roll over to use the new KSK.
The time to do this is NOW to be ready for the Root KSK Roll when it does happen.
For more information about DNSSEC in general, please see our Deploy360 DNSSEC page.
Image credit: Lindsey Turner on Flickr. CC BY 2.0
P.S. And no, that is NOT what the “Root key” looks like!