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.
