[dns-operations] Root KSK Rollover Postponed

[Keith Mitchell]

Forwarding an official ICANN posting from Matt on this which seems to
have got stuck in the tubes somewhere:

>> From: Matt Larson <matt.larson at icann.org>
>> Subject: Root KSK roll delayed
>> Date: September 28, 2017 at 9:47:14 AM PDT
>> To: dns-operations <dns-operations at dns-oarc.net>
>>
>> ICANN has decided to postpone the root KSK roll previously
>> scheduled for 11 October 2017 for at least one quarter. This
>> message gives some background and explanation for that decision.
>> 
>> Historically there has been no way to determine which trust anchors
>> DNSSEC validators have configured, making it difficult to assess
>> the potential impact of the root KSK rollover. "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, and only the most recent versions of BIND (9.10.5b1 and
>> 9.11.0b3 and later) and Unbound (1.6.4 and later) support it. This
>> protocol was not expected to have sufficient deployment to provide
>> useful information for the first root KSK rollover.
>> 
>> However, initial research by Verisign and then by ICANN has found a
>> growing number of validators reporting trust anchor configuration
>> to the root servers. Based on data from six root server addresses,
>> approximately 12,000 unique source IP addresses have sent trust
>> anchor configuration reports so far in September 2017. The number
>> reporting is growing and now approaches 1400 unique addresses per
>> day. Significantly, approximately 5% of the total validators and
>> about 6%-8% on any given day report only KSK-2010, the root zone
>> KSK currently signing the root's DNSKEY RRset. These validators
>> would not resolve correctly after the planned root KSK roll.
>> 
>> There are various reasons a validator might report only KSK-2010.
>> One reason is an old configuration with a statically configured
>> trust anchor (e.g., BIND's "trusted-key" statement). ICANN has
>> always known that a small percentage of validators would not be
>> ready for the rollover because they had manually configured their
>> trust anchor, and that operators of those validators would need to
>> take action when the root KSK rollover happened.
>> 
>> Another reason is 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. Based on our
>> research and preliminary investigation, we also believe it is
>> possible that some operators believe that they are ready for the
>> rollover because they configured their validator to use RFC 5011
>> automated updates, but will not trust KSK-2017 when the rollover
>> happens due to configuration issues or software defects.
>> 
>> Given the relatively high percentage of validators with just
>> KSK-2010, ICANN believes it is important to better understand the
>> reasons before proceeding with the root KSK roll. We will soon be
>> publishing the list of resolvers reporting only KSK-2010 and will
>> ask for the operational community's help in identifying, diagnosing
>> and correcting these systems.
>> 
>> Throughout the project we have emphasized that the root KSK is
>> being rolled under normal operational conditions and have proceeded
>> cautiously and without haste. 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
>> KSK-2010.
>> 
>> 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.
>>
>> Matt
>> --
>> Matt Larson, VP of Research
>> ICANN Office of the CTO