Hello,
I am forwarding the following message about the DNSSEC Root KSK roll:
Regards,
S. Moonesamy
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
Received on Thu Sep 28 2017 - 20:46:04 PST