Five years ago, in June 2010, ICANN signed the Root Zone of the DNS, enabling DNS resolvers to use a single root key to validate the signed responses they receive in the DNS. This was a significant change to the DNS, and many DNS resolvers then started using DNSSEC signatures to validate what they learn from their DNS queries.
The change has been dramatic and today, according to measurements undertaken by APNIC’s Chief Scientist, Geoff Huston, one quarter of the world’s Internet users pass their queries to DNSSEC-validating resolvers. That’s a significant change for the security of the DNS in just five years.
All of this validation relies on a single injection of “trust material,” and for the DNS this trust anchor is the Key-Signing Key (KSK) of the Root Zone of the DNS. Every DNSSEC-validating resolver has its local copy of this key, and it’s this single key that allows all the signing chains in the DNS to be validated.
DNSSEC relies on the natural structure of DNS names to perform validation, using a signing chain defined by DNSSEC. For example, the key used to sign the DNS name “www.example.com” is the zone signing key of “example.com,” which is the every day working key of example.com. This key is signed over by the key-signing key of “example.com.” This key, in turn, is signed over by the zone signing key of “.com”, which, is signed over by the “.com” key-signing key. This key is then signed over by the zone signing key of the Root Zone, which is itself signed over by the Root Zone KSK. A validating resolver can retrace this chain of key signings and if it can validate the signing chain to the KSK, then the original DNS response is proved good.
All this relies on all validating resolvers having a local current copy of the Root Zone KSK. Cryptographers recommend that it’s unwise for any key to be used forever, and good security practice involves a regularly scheduled roll of keys. The DNS Root Zone KSK uses a five year key roll schedule.
It’s 2015, and that means it’s time for the KSK to roll. ICANN, as the operator of the IANA functions, is managing a process to prepare for the roll over of the KSK. The preparations for this have been underway for some time now – in 2012 ICANN began its first public consultation process on the KSK roll over – as it will not be a trivial exercise.
The problem is that a roll of the Root Zone KSK has never been done before. While there is a standard specification of how a resolver can update its local copy of the KSK (documented in RFC 5011) it’s not clear how many DNSSEC-validating resolvers support this standard. Those resolvers that don’t support RFC5011 will be left stranded with the old KSK value and will no longer operate as intended until an operator reloads the resolver with the new KSK value.
The key roll also involves a period of slightly larger responses from the Root Zone, of up to 1,425 octets. This should not present a major issue, but it is above the 1,232 octet maximum unfragmented DNS payload in IPv6, and there are some concerns relating to UDP fragmentation in IPv6 and the fallback to TCP that have yet to be quantified.
Given these unknowns, this roll of the KSK is going to need to be handled carefully for DNSSEC to continue to operate properly for the pool of 750 million users who already rely on it.
Following the initial consultations and reports, a design team of global experts has been recruited to develop a plan with ICANN on how best to roll over the Root Zone KSK causing the minimum amount of disruption to the DNS. That team (which includes APNIC’s Geoff Huston) is currently working on a proposal which will be presented to the Internet community for public comment in the coming months.
APNIC will certainly alert the community when this happens as your feedback will be important in this process.
Once the public comment period ends, and those comments are considered, a final plan will be agreed, communicated and executed.
But as ICANN’s Ed Lewis presented at RIPE 70, any plan will face external challenges. Ed posed these questions:
- Will validators have trouble receiving responses during the roll?
- Are automated trust anchor updates implemented correctly?
- Will operators know how to prepare, how to react?
- Will all DNSSEC code paths perform correctly?
As part of his work in the design team, Geoff has been researching some of these issues and he presented some of his initial findings following Ed’s presentation at RIPE 70.
If you are interested in finding out more, on DNSSEC and the Root Zone KSK, IANA’s DNSSEC page has a lot of helpful information.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.