Skip to main content

Root Zone KSK Rollover

This page has general information about the KSK rollover. If you came here looking how to update to the latest KSK trust anchor, please see this page.

Root Zone KSK Rollover

Get Involved
Draft Timeline
Operational Plans
Communications Plan

Technical Updates

23 April 2018 – Staff report on the Draft Plan Comments published

18 December 2017 – Update on the Root KSK Rollover Project

17 October 2017 – Postponing the Root KSK Roll

27 September 2017 – ICANN announces a postponement for the KSK Rollover

4 September 2017 – Checking the Current Trust Anchors in DNS Validating Resolvers

4 September 2017 – Updating of DNS Validating Resolvers with the Latest Trust Anchor

11 July 2017 – KSK-2017 is published in the DNS


ICANN is planning to perform a Root Zone Domain Name System Security Extensions (DNSSEC) KSK rollover as required in the Root Zone KSK Operator DNSSEC Practice Statement [TXT, 99 KB].

Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root's "trust anchor." The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet's DNS.

Maintaining an up-to-date KSK is essential to ensuring DNSSEC-validating DNS resolvers continue to function following the rollover. Failure to have the current root zone KSK will mean that DNSSEC-validating DNS resolvers will be unable to resolve any DNS queries.

The KSK rollover plans were developed by the Root Zone Management Partners; ICANN in its role as the IANA Functions Operator, Verisign 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 role of NTIA ended on 1 October 2016. The KSK rollover plans were posted in July 2016 and incorporate the community Root Zone KSK Rollover Design Team recommendations [PDF, 1.01 MB].


Related information and additional resources can be found at:

العربية | Español | Français | 日本語 | 한국어 | Português | Pусский | 中文

Get Involved

Ask a Question
Send an email to with "KSK Rollover" in the subject line to submit your questions.

Engage on Social Media
Use the hashtag #KeyRoll to join the conversation:

Join the KSK Rollover Discussion List
Sign up to the mailing list for public discussions on related issues:

Spread the Word
Share this webpage with others to help them learn about the KSK rollover and how they may be impacted.


In 2009, the RZM partners collaborated to deploy DNSSEC in the root zone, which culminated in the first publication of a validated signed root zone in July 2010.

The requirements [PDF, 116 KB] for generating and maintaining the root zone KSK, as well as the respective responsibilities of each of the RZM partners, were specified by NTIA. The procedures by which those requirements were met by the Root Zone Maintainer (Verisign) and the IANA Functions Operator (ICANN) were published in separate DNSSEC Practice Statements (DPS): Verisign DNSSEC Signing Service DPS [PDF, 138 KB] and Root Zone KSK Operator DPS [TXT, 99 KB].

The IANA Functions Contract between NTIA and ICANN was modified in July 2010 to include responsibilities associated with Root Zone KSK management, and those requirements have been carried forward in subsequent revisions of that contract.

The Cooperative Agreement between NTIA and Verisign was also amended in July 2010 to reflect Verisign's Root Zone ZSK Operator responsibilities.

The IANA Functions Contract required a Root Zone KSK rollover, but did not provide detailed requirements, or a detailed timeline or implementation plan. The Root Zone KSK Operator DPS contains this statement, laying a requirement for a rollover in Section 6.5:

"Each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation."


  • October 27 2016: KSK rollover process begins as the new KSK is generated.
  • July 11 2017: Publication of new KSK in DNS.
  • September 19 2017: Size increase for DNSKEY response from root name servers.
  • 1 February 2018: Public comment period for plan to resume the KSK rollover begins, ends 2 April 2018.
  • 23 April 2018: Staff report on the Draft Plan Comments published.
  • 13 May 2018: ICANN Board requests RSSAC, SSAC and RZERC advice on Draft Plan.
  • 11 October 2018: KSK rollover (subject to change based on operational considerations).

Operational Plans

ICANN publishes its operational plans for the KSK rollover so that the community can know what to expect is coming. Please see this page for both the current operational plans and the plans that were used earlier.

Communications Plan

ICANN is executing an extensive outreach campaign to ensure that those who currently use the KSK know about the change.

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