Skip to main content

DNSSEC: Rolling the Root Zone Key Signing Key

Ksk rollover 750x480 en

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 Please share this resource with others and encourage them to learn about these upcoming changes to the DNS.


    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."