Skip to main content

The Recent KSK Rollover: Summary and Next Steps

As we hope you have already heard, the main cryptographic key for the DNS root zone was changed on 11 October 2018 in an elaborately orchestrated series of steps. The result was exceptionally good: There were far fewer Internet users negatively affected by the change (called a rollover) than anyone expected. There are a few more things that need to be done for the rollover process to be considered complete, but the main task went off without a hitch.

A bit of background: the rollover had been foreseen since the root zone was first signed with DNSSEC in 2010. Planning started in earnest in December 2014 when ICANN solicited volunteers from the community to collaborate with the design team to develop a rollover plan for the root zone key-signing key, or KSK (The KSK signs the other keys in the zone, called the ZSKs). That plan was published in March 2016 and reviewed by the community. ICANN org turned the design into specific operational plans (detailed here), and started putting them into action in early 2017. The plans contained extensive outreach to resolver operators to make sure they were prepared.

The rollover was slated for 11 October 2017, but was postponed due to confusing signals being observed in the root server system. After those signals were thoroughly evaluated, ICANN proposed to the community [PDF, 162 KB] that the rollover be re-slated for 11 October 2018, and the ICANN Board approved the new timing in September 2018.

When 11 October arrived, we went through the operational plans step-by-step and at 1600 UTC, the KSK used to sign the root zone was changed to the new key that had been generated in 2017. We anticipated that some resolver operators would not be ready regardless of how much we attempted to find and communicate with them ahead of time. But as the ICANN org and the DNS technical community watched the post-rollover reports, it became apparent that resolver operators were well-prepared. Even now, more than two weeks after the rollover, we have heard of only a handful of resolvers that were negatively affected and, as far as we know, all were able to recover. ICANN has heard of only two Internet Service Providers (ISPs) who experienced outages around the time of the rollover and who might have been negatively affected by the rollover, but we have not been able to investigate the root cause of their problems yet.

There are still a few things left to do. First, the old key needs to be formally revoked. On 11 January 2019, the old key, which has continued to be published in the root zone, will be changed to indicate it's no longer valid and that resolvers should delete it from their configurations. Soon after that, ICANN will publish an extensive white paper covering the entire rollover process, including lessons learned from the effort. Then, ICANN's many communities will start to discuss what they want to see from future rollovers (e.g. how often they should happen, the use of "stand-by" keys, and the kind of data that they want to see before rollovers), all based on what we learned from the planning process and execution of this rollover.

If you are interested in keeping up with the remaining steps of the first root KSK rollover and the discussion of future rollovers, please join the ksk-rollover mailing list.


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