Internet Corporation for Assigned Names and Numbers (ICANN), which administers the Internet namespace, has been engaged in a multi-year effort to update the cryptographic keys used to protect the Domain Name System (DNS) from abuse. The new root zone \u201ckey signing key\u201d (KSK) used to secure DNS was generated last year.Internet service providers, hardware manufacturers, and enterprises that operate their own recursive name servers and use Domain Name System Security Extensions (DNSSec) validation to protect their domains, needed to update their system with the public part of the key pair by October 11. On that day, ICANN planned to \u201crollover,\u201d to start using the new root zone key signing key sign domains. If the systems aren\u2019t updated with the new public key, when the old key is finally revoked in 2018, DNSSEC validations will fail and cause DNS to break.\u00a0Based on data ICANN received from the root zone servers, a \u201csignificant number\u201d of resolvers used by ISPs and large network operators are not ready to use the new keys. Updating the encryption keys used to secure the Internet\u2019s foundational servers is an exceptionally dicey challenge, so it makes sense to change the deadline and give network operators more time. Don\u2019t knock as many as 60 million people offline."It would be irresponsible to proceed with the rollover after we have identified these new issues that could adversely affect its success and could adversely affect the ability of a significant number of end users," says Goran Marby, CEO of ICANN. \u201cWe would rather proceed cautiously and reasonably.\u201dICANN did not announce a new deadline, but says the rollover will be rescheduled to the first quarter of 2018. The administrative body will use the extension to reach out to those ISPs and network operators it had identified to work with them to resolve issues.Missing the deadline would have serious consequences for regular Internet users. ICANN estimates about 750 million people browse the web using information provided by DNSSEC servers. \u201cThose 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,\u201d says internet security pioneer Paul Vixie, currently the CEO of Farsight Security and longtime DNS and DNSSEC developer."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\u2019s ultimate root keyThe Domain Name System (DNS) acts as the internet\u2019s 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\u2019t 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\u2019re getting good results to their queries. That a given IP address really does resolve to that domain.There is nothing wrong with the key\u2014it hasn\u2019t been stolen or tampered with\u2014but 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\u2014for the key to be cracked, for example\u2014before updating to a newer, stronger, key.\u00a0\u201cUpdating the DNSSEC KSK is a crucial security step, similar to updating a PKI Root Certificate,\u201d the United States Computer Emergency Response Team (US-CERT) wrote in a recent advisory. \u201cMaintaining an up-to-date Root KSK as a trust anchor is essential to ensuring DNSSEC-validating DNS resolvers continue to function after the rollover.\u201dRollover process hits a glitchICANN 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.\u201cThere 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,\u201d ICANN says.It could also be an awareness issue\u2014that enough operators were not aware of the deployment process. \u201cICANN is on schedule to begin using the private portion [for signing domains] shortly,\u201d Vixie says.The most challenging part of this multistep, multi-year process was overseeing the plan\u2019s 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\u2014or 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\u00a0testing platform\u00a0to 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.\u00a0It 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.\u00a0Verify the updatesWhile 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.\u00a0DNSSEC 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\u2019s 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 \u201cuseless for predicting the results for the full population,\u201d 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\u2019s up to everyone else in the trust chain to do their part. \u201cIn this sense, we are benefitting from the fairly sparse and narrow adoption of DNSSEC,\u201d Vixie says, noting that the community is dominated by late adopters and those who understand the issues in detail. \u201cOnly an early adopter who has been living on Mars for the last few years could be expected to have trouble.\u201d[Related: DNS record will help prevent unauthorized SSL certificates]Vixie says he was \u201cextremely impressed\u201d 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.\u201cI predicted early on that this could not be done without far more delay and pain than I've seen,\u201d Vixie says. \u201cIn 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\u00a01,024-bit RSA key as originally reported.