Read ICANN Blogs to stay informed of the latest policymaking activities, regional events, and more.

DNSSEC: Rolling the Root Zone Key Signing Key

22 July 2016
By David Conrad

In addition to the ICANN Languages, this content is also available in


ICANN today posted plans to update or "roll" the Root Zone Key Signing Key (KSK), marking another significant step in our ongoing efforts aimed at improving the security of the Domain Name System (DNS).

The KSK rollover plans were developed by the Root Zone Management Partners: ICANN in its role as the IANA Functions Operator, Verisign acting as the Root Zone Maintainer, and the U.S. Department of Commerce's National Telecommunications and Information Administration (NTIA) as the Root Zone Administrator. The plans incorporate the March 2016 recommendations [PDF, 1.01 MB] of the Root Zone KSK Rollover Design Team, after it sought and considered public comment on a proposed rollover process.

What is the KSK?

The KSK is a cryptographic public-private key pair that plays an important role in the Domain Name System Security Extensions (DNSSEC) protocol. The public portion of the key pair serves as the trusted starting point for DNSSEC validation, similar to how the root zone serves as the starting point for DNS resolution. The private portion of the KSK is used during the Root KSK Ceremonies to sign the Zone Signing Keys used by Verisign to DNSSEC-sign the root zone.

Why Roll the KSK?

Good security hygiene recommends passwords be changed periodically to reduce the risk that those passwords can be compromised via brute force attacks. As with passwords, the community has informed us that the cryptographic keys used to sign the root zone should be periodically changed to help maintain the integrity of the infrastructure that depends on those keys and ensure that security best practices are followed.

The KSK Rollover Process

Rolling the KSK involves creating a new cryptographic key pair that will be used in the DNSSEC validation process to verify that responses to queries for names in the root zone (typically TLDs) have not been altered in transit. Transitioning to that new key pair and retiring the current key pair is also part of the rollover process. Internet service providers, enterprise network operators, and others who have enabled DNSSEC validation must update their systems with the new public part of the KSK, known as the root's "trust anchor." Failure to do so will mean DNSSEC-enabled validators won't be able to verify that DNS responses have not been tampered with, meaning those DNSSEC-validating resolvers will return an error response to all queries.

Because this is the first time the root's KSK key pair will be changed since it was generated in 2010, a coordinated effort is required across many in the Internet community to successfully ensure all relevant parties have the new public portion of the KSK and are aware of the key roll event. ICANN will be discussing the KSK rollover at various technical fora and using the hashtag #KeyRoll to aggregate content, provide updates, and address inquiries on social media. We have also created a special online resource page to keep people up to date with key roll activities.

If the KSK rollover is smoothly completed, there will be no visible change for the end user. But as with pretty much any change on the Internet, there is a small chance that some software or systems will not be able to gracefully handle the changes. If complications become widespread, the Root Zone Management Partners may decide that the key roll needs to be reversed so the system can be brought back to a stable state. We have developed detailed plans that will enable us to back out of the key roll in such a circumstance.


The KSK rollover will take place in eight phases, which are expected to take about two years. The first phase is scheduled to begin in Q4 of 2016.

Next Steps

Developers of software supporting DNSSEC validation should ensure their product supports RFC 5011. If their products do, then the KSK will be updated automatically at the appropriate time. For software that does not conform to RFC 5011, or for software which is not configured to use it, the new trust anchor file can be manually updated. This file will be available here and should be retrieved before the resolver starts up and after the KSK is changed in the DNSKEY Resource Record Set (RRset) of the DNS root zone.

ICANN has developed operational tests that software developers and operators of validating resolvers can access to evaluate whether their systems are prepared for the KSK rollover. You can learn more about these tests here [PDF, 519 KB].

As the KSK rollover draws nearer, all interested parties can learn more and get updates at https://www.icann.org/kskroll. Please share this resource with others and encourage them to learn about these upcoming changes to the DNS.


David Conrad

David Conrad