Skip to main content

The Story Behind ICANN’s Decision to Delay the KSK Rollover

Most are now aware of ICANN's announced decision to postpone the changing of the cryptographic key that helps protect the Domain Name System (DNS). This change or "roll" was originally scheduled for 11 October.

I would like to provide some additional details about what went into our decision to delay the roll. You might say it's the story behind the story.

Historically, there has been no way to determine which trust anchors DNS Security Extensions (DNSSEC) validators have been configured, making it difficult to assess the potential impact of the root KSK rollover. But that recently changed and we received some new data that we simply could not ignore.

"Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)" (defined in RFC 8145) is a recent protocol extension that allows a validator to report which trust anchors it has configured for a zone to that zone's name servers.

The protocol was only finalized in April 2017, though it is supported only by the most recent versions of some widely used resolver software (BIND 9.10.5b1 and 9.11.0b3 and later and Unbound 1.6.4 and later). Initially, this protocol was not expected to be deployed widely enough to provide useful information for the first root KSK rollover.

However, some very initial research (by Verisign and later ICANN) found a growing number of validators reporting trust anchor configuration to the root servers. Data from six root server addresses indicates that for the month of September 2017, approximately 12,000 unique source IP addresses sent trust anchor configuration reports. The number reporting is growing and now approaches 1400 unique addresses per day.

Those incoming reports indicate that approximately 5% of the total validators and about 6%-8% on any given day report they are using KSK-2010, which is the root zone KSK currently signing the root's DNSKEY RRset. Importantly, these validators would not resolve correctly after the planned root KSK roll.

Based on this new information, we decided to postpone the root KSK roll for at least one quarter.

Throughout the project we have emphasized that the root KSK is being rolled under normal operational conditions and have proceeded cautiously and without any rush. The decision to postpone was taken in that spirit of caution because there is no operational pressure to proceed given our continued confidence in the security of the current key, KSK-2010.

There are various reasons a validator might report only KSK-2010: an old configuration with a statically configured trust anchor (e.g., BIND's "trusted-key" statement) or a failure to automatically update the trust anchor using the RFC 5011 automated update protocol because of a software defect, operator error or other reason.

Given the relatively high percentage of validators with just KSK-2010, ICANN believes it is important to understand the reasons before proceeding with the root KSK roll. We will soon be publishing the list of validators reporting only KSK-2010 and will ask for the operational community's help in identifying, diagnosing and correcting these systems.

We appreciate the community's understanding and we look forward to your assistance in gathering the information necessary to move forward with the root KSK roll.


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