Skip to main content

Update on the Root KSK Rollover Project

The ICANN org is today announcing that it will not roll the root zone KSK in the first quarter of 2018.

We have decided that we do not yet have enough information to set a specific date for the rollover. We want to make clear, however, that the ICANN org is committed to rolling the root zone KSK and we will continue to discuss this important process with the community, gather their feedback and give all interested parties advance notice of at least one calendar quarter when we set the date for the rollover.

Furthermore, we are soliciting input from the community to help determine, if possible, appropriate objective criteria to measure the possible negative impact of the root KSK rollover on Internet users, and acceptable values for those criteria before a rollover. This is in accordance with the bottom-up, multi-stakeholder model that has been so successful for ICANN policy development.

On 27 September 2017, the ICANN org announced it was postponing the root zone KSK rollover for at least one quarter, leaving open the possibility the root KSK rollover might occur in the first quarter of 2018. We have since realized that our analysis and preparation will require additional time.

In a previous post, we described our analysis of recursive resolver trust anchor configuration information reported using the protocol defined in RFC 8145, Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC). Our analysis revealed that about 4% of the approximately 12,000 DNSSEC-validating resolvers reporting during the month of September 2017 were configured with only KSK-2010 (the shorthand for the current root KSK) and would have been unable to resolve DNS queries after the rollover occurred.

The ICANN org's decision to postpone the rollover was based on the concern that we did not understand why those resolvers were not properly configured, and we needed time to investigate.

Since then, we have attempted to contact the operators of 500 addresses that had reported a resolver configuration with only KSK-2010 instead of the correct configuration of both KSK-2010 and the new KSK, KSK-2017. Ideally, that investigation would have revealed a set of clear causes for the improper configuration, allowing further communication and actions to be targeted at addressing those specific issues. But in the end, the analysis was not as conclusive as we would have hoped.

In our initial attempt, we received a response from operators of approximately 20% of the 500 addresses. Of those addresses whose operators we could contact, 60% came from address ranges known to host devices with dynamic addresses, such as routers of home broadband users and ephemeral virtual machines, making these resolvers extremely difficult (if not impossible) to track down. About 25% of the addresses corresponded to a resolver forwarding on behalf of another resolver that was reporting only KSK-2010. Since the address of the device reporting the incorrect configuration was not the actual source resolver, it is extremely difficult (if not impossible) to identify the true source address of the resolver that was reporting only KSK-2010.

To proceed with the root KSK rollover, the ICANN org must have confidence that the rollover will not have an unacceptable negative impact on Internet users. The challenge we have encountered since we began to analyze the RFC 8145 trust anchor configuration reports from resolvers is assessing the impact on users.

We can make a number of assumptions: for example, it is unlikely that a recursive resolver running at a dynamic address could support a large number of users since it does not offer a stable address for any devices to send queries to for resolution. But ultimately, determining potential user impact based on the data available to us is difficult and we are therefore soliciting the community's input.

Input and discussion on acceptable criteria for proceeding with the KSK roll will take place on an existing email list that is already being used for discussion of the root KSK rollover. We encourage anyone interested in contributing to join the mailing list by visiting the web page here.

The ICANN org will monitor this mailing list and beginning on 15 January 2018, we will develop a draft plan for proceeding with the root KSK roll based on the input received and discussion on the mailing list. The plan will be published by 31 January 2018 and undergo a formal ICANN public comment process to gather further input. We will hold a session at ICANN61 in San Juan, Puerto Rico, to discuss the plan and hear from the community in person. Our intent is to have a revised plan available for community review and public comment prior to ICANN62 in Panama City, Panama, with a final plan published soon thereafter.

Throughout the process we'll continue to keep the community updated on the root KSK rollover project's progress.


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