DNSSEC key signing key rollover: Are you ready?
Enterprises that rely on the DNSSEC protocol need to update their name servers before 11 OctoberPrint
12 September 2017 | 0
The October deadline for changing the root zone key signing key (KSK) for the Domain Name System Security Extensions (DNSSec) is fast approaching. Enterprises that operate their own recursive name servers and use DNSSec validation to protect their domains must make sure systems have been updated with the new signing keys or risk having users unable to access portions of the Internet.
The Internet Corporation for Assigned Names and Numbers (ICANN) will start using the new root zone key signing key generated late last year to sign domains starting 11 October. Internet service providers (ISP), enterprise network operators, hardware manufacturers, and application developers performing DNSSEC validation need to update their systems with the public part of the key pair by the deadline. If the systems aren’t updated with the new public key, when the old key is finally revoked in 2018, DNSSEC validations will fail and cause DNS to break.
“Those who suffer will be those whose recursive name server operators performing DNSSec validation but which have not correctly received, stored, and configured the new key during its pre-publication period,” said Internet security pioneer Paul Vixie, currently the CEO and founder of Farsight Security.
DNSSEC’s ultimate root key
The Domain Name System (DNS) acts as the internet’s phone book, translating IP addresses to easy-to-remember domain names. However, the distributed nature of DNS makes the system vulnerable to hijacking as users get diverted to fraudulent sites through DNS cache poisoning or DNS spoofing. The DNSSEC protocol, introduced in 2010, thwarts hijacking by using cryptographic key pairs to verify and authenticate the results of a DNS lookup. If the DNS response has been tampered with, the keys don’t match and the browser returns an error instead of sending users to the incorrect destination.
DNSSEC works as a hierarchy with different bodies responsible for each layer and signing the key of the entities in the layer below. The key signing key is a cryptographic public-private key pair, and the root zone KSK secures the topmost layer of the hierarchy, the starting point for DNSSEC validation.
The current KSK is the original 1,024-bit RSA key generated back in 2010 when the protocol was first introduced. There is nothing wrong with the key – it hasn’t been stolen or tampered with – but it is good security practice to periodically rotate the signing key so that even if it falls into the wrong hands, everyone is already using the newer, stronger key. The changeover is also necessary as the 1,024-bit keys are no longer considered secure enough for modern Web applications. There is no reason to wait for something bad to happen – for the key to be cracked, for example – before updating to the stronger 2,048-bit key.
“Updating the DNSSEC KSK is a crucial security step, similar to updating a PKI Root Certificate,” the United States Computer Emergency Response Team (US-CERT) wrote in a recent advisory. “Maintaining an up-to-date Root KSK as a trust anchor is essential to ensuring DNSSEC-validating DNS resolvers continue to function after the rollover.”
Rollover is proceeding as planned
ICANN and volunteers from the global technical community spent the last five years developing, reviewing, refining, and testing the rollover plan before kicking off the process last year by generating the new KSK. In July, ICANN published plans outlining the steps required to rollover the KSK so that ISPs, enterprise network operators, hardware manufacturers, and others performing DNSSEC validation can update their systems with the public part of the key pair. Even though the new key signing key will start being used to sign domains in October, DNSSEC will support both the old and new keys until early 2018 to give everyone time to complete the rollover process.
“ICANN is on schedule to being using the private portion [for signing domains] shortly,” Vixie said.
The most challenging part of this multistep, multi-year process was overseeing the plan’s development, seeking broad review and approval, and obtaining approvals from multiple Internet governance organizations to execute the plan, Vixie said. The ICANN Office of the CTO has already done the hard part; the technical implementation and publicising the process is the easy part.
Many organisations operate validating name servers including ISPs, enterprises, universities, small offices, and even hobby users. Most of these recursive name servers have likely already received out-of-band key updates from their vendors through their normal software update process – or are scheduled to receive one over the next few weeks.
Administrators need to manually update DNSSEC validators lacking RFC 5011 support (automated updates) as they would not automatically receive, store, and configure the new key. Any DNSSEC validators offline during this period can theoretically update itself after the new key is in full effect and get up to speed, but that will happen only if those validators are online before March, before the old key is officially retired.
It is theoretically possible for a DNSSEC validator to miss all the update opportunities and not receive the new key from its root trust anchor. If that is the case, that validator will fail DNSSEC validation on all responses received from root name servers come March 2018 when the old key is revoked. That scenario is most likely to happen with test labs and not production networks, Vixie said.
Verify the updates
While most name servers are being updated automatically, every recursive validating name server operator should check by hand to ensure that the new key has been received, stored, and configured for validation use. There is no need to wait until DNSSEC validation fails to discover the update was incomplete.
DNSSEC validation is mandatory for federal agencies, and adoption in the private sector has been slow. Even so, ICANN estimates that 750 million people worldwide rely on DNSSEC validation and will be affected by the rollover. While it’s theoretically possible to estimate how many enterprises are ready for the deadline, the number of public-facing recursive name servers performing DNSSEC validation is so small it would be “useless for predicting the results for the full population,” Vixie said.
At this point, the only thing to do is wait and see what happens when the old key is no longer in use – and hope that everyone has done their part. “In this sense, we are benefitting from the fairly sparse and narrow adoption of DNSSEC,” Vixie said, noting that the community is dominated by late adopters and those who understand the issues in detail. “Only an early adopter who has been living on Mars for the last few years could be expected to have trouble.”
Vixie said he was “extremely impressed” at how the rollover implementation plan was conceived and executed. The fact that the rollover is proceeding according to plan makes it possible to have this kind of key rotation done on a regular basis. The next rollover is expected in 2022.
“I predicted early on that this could not be done without far more delay and pain than I’ve seen,” Vixie said. “In the near future, it [the rotation] will no longer even be newsworthy.”
IDG News Service