Skip to main content
Resources

Root Zone KSK Rollover

Root Zone KSK Rollover

Overview
Resources
Get Involved
Background
Draft Timeline
Operational Plans
Communications Plan

Technical Updates

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

27 April 2017 – First set of Key Signing Requests (KSRs) signed with new key

2 February 2017 – KSK-2017 replicated at the second Key Management Facility

27 October 2016 – The new KSK ("KSK-2017") was successfully generated at the first Key Management Facility

19 September 2016 – First step of 2017 KSK Rollover Test Plan completed

Overview

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.

ICANN is offering a testing platform for operators or any interested parties to confirm that their systems handle the automated update process correctly. Check to make sure your systems are ready by visiting go.icann.org/KSKtest.

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

Resources

Related information and additional resources can be found at:

Get Involved

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

Attend an Event
View the events calendar to find upcoming KSK rollover presentations.

Engage on Social Media
Use the hashtag #KeyRoll to join the conversation: https://twitter.com/icann

Join the KSK Rollover Discussion List
Sign up to the mailing list for public discussions on related issues: https://mm.icann.org/listinfo/ksk-rollover

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

Background

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

Timeline

These times are subject to change based on operational considerations.

  • 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.
  • October 11, 2017: New KSK begins to sign the root zone key set (the actual rollover event).
  • January 11, 2018: Revocation of old KSK.
  • March 22, 2018: Last day the old KSK appears in the root zone.
  • August 2018: Old key is deleted from equipment in both ICANN Key Management Facilities.

Operational Plans

  1. 2017 KSK Rollover Operational Implementation Plan [PDF, 741 KB] - Describes in detail the operational steps to accomplish the 2017 KSK Roll project, including the timeline of the eight phase process.
  2. 2017 KSK Rollover Back Out Plan [PDF, 506 KB] - Describes anticipated deviations from the Operational Implementation Plan based on anomalies occurring while executing the operational plan.
  3. 2017 KSK Rollover External Test Plan [PDF, 516 KB] - Covers the preparation of operational test environments, accessed by the general Internet public, to evaluate whether external systems are prepared to participate in the KSK roll.
  4. 2017 KSK Rollover Monitoring Plan [PDF, 480 KB] - Describes the plan to monitor the effects of changing the trust anchor for the root zone in the traffic towards root servers.
  5. 2017 KSK Rollover Systems Test Plan [PDF, 519 KB] - Describes the actions needed to test changes to ICANN's infrastructure involved in the KSK roll.

Communications Plan

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

Read the Communications Plan.

News Archive

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""icann.org"" is not an IDN."