DNSSEC key signing key rollover: Are you ready?

“DNSSEC deployment has been slow, and I expected that the early adopters would be those most ready to handle something like a key rollover event,” says Vixie. “ICANN has displayed a commendable abundance of caution throughout the rollover planning and execution, and one of their gut checks was to measure the adoption rates of the new key they’re hoping to roll over to. They found slightly more than one out of 20 DNSSEC-capable networks to only have the old key. That’s too high, and so they’ve postponed the rest of the execution of the rollover plan until they can resolve this adoption problem.”

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 anchor point for DNSSEC validation.

DNS resolvers rely on the chain of trust the KSK builds from the root zone down through each layer of the system to verify they’re getting good results to their queries. That a given IP address really does resolve to that domain.

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. There is no reason to wait for something bad to happen—for the key to be cracked, for example—before updating to a newer, stronger, 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 process hits a glitch

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.

“There may be multiple reasons why operators do not have the new key installed in their systems: some may not have their resolver software properly configured and a recently discovered issue in one widely used resolver program appears to not be automatically updating the key as it should, for reasons that are still being explored,” ICANN says.

It could also be an awareness issue—that enough operators were not aware of the deployment process. “ICANN is on schedule to begin using the private portion [for signing domains] shortly,” Vixie says.

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 says. The ICANN Office of the CTO has already done the hard part; the technical implementation and publicizing the process is the easy part.

Many organizations 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.

ICANN advises that network operators and ISPs ensure their systems are ready for the new rollover data, and to make use of its testing platform to ensure resolvers are properly configured. 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 says. 

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 says.

ICANN decided to slow down because there were too many operators that were not ready. It will continue evaluating and reassessing, but at this point, it’s up to everyone else in the trust chain to do their part. “In this sense, we are benefitting from the fairly sparse and narrow adoption of DNSSEC,” Vixie says, 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.”

[Related: DNS record will help prevent unauthorized SSL certificates]

Vixie says 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 says. “In the near future, it [the rotation] will no longer even be newsworthy.”

Editor’s Note: This story was updated to reflect that the current KSK is 2,048-bit RSA key, and not 1,024-bit RSA key as originally reported.