ICANN ICANN Email List Archives

[comments-root-zone-consultation-08mar13]


<<< Chronological Index >>>    <<< Thread Index >>>

Comment on Root Zone Key Rollover

  • To: <comments-root-zone-consultation-08mar13@xxxxxxxxx>
  • Subject: Comment on Root Zone Key Rollover
  • From: Geoff Huston <gih@xxxxxxxxx>
  • Date: Fri, 5 Apr 2013 13:03:46 +1100

Some earlier experience in DNSSEC key rollover may be relevant to this
consideration of rolling the KSK of the root of the DNS

The RIPE NCC was practising regular (6 monthly) key rollover in 2008/2009,
and it was noted that in the priod following each key rollover event the
number of queries to the authoritative name servers to these domains
increased.

An analysis of this situation (The report “Roll Over and Die," at
<http://www.potaroo.net/ispcol/2010-02/rollover.html>) noted that
DNSSEC-aware servers which did not implement RFC5011 were capable of
creating large persistent flows of DNS query through all NS of a zone,
seeking validation, when the signature validation chain to the trust anchor
was broken. This was observed in the in-addr.arpa tree when the RIPE NCC
rolled its trust and did not update the setaside root trust path at ISC,
and was observed at .SE during a broken key rollover. At that time, DNSSEC
was not widely deployed, and few resolvers had implemented the measures
described in RFC5011.

In March 2013 we have gathered experimental evidence that points to a level
of DNSSEC validation where some 5.5% of Internet end systems use DNS
resolvers that perform DNSSEC validation. This may seem to be a relatively
small proportion, but in a global space of 350,000,000 queries per day into
in-addr.arpa, represents some 19,500,000 queries per day potentially
capable of triggering this situation. In the larger context of all
DNNSEC-signed zones, this number is of course far larger.

However, the mitigation here is the level of use of RFC5011 key rollover
management. To the best of our knowledge, RFC5011 was introduced in Bind
version 9.7, and a number of patches were released for older codebases. We
therefore are wondering what percentage of resolvers worldwide implement
DNSSEC but do not support RFC5011, as these resolvers represent the
population of resolvers that are capable of generating this persistent
traffic to the root zone servers in the even of key rollover at the root.

It is not clear what the consequences of a key rollover at the root will be
without an analysis of the number of resolvers still relying on hand
installed trust anchor material, and deployment of validation, which lie
along DNS resolver chains with pre-9.7 bind code. 

What is clear is that the combination of older resolvers that do not
support RFC5011, and include code that performs comprehensive path
searching in the event of signature validation failure has the potential to
dramatically increase the query levels on the root servers, and on the
DNSSEC-signed child servers. We do not understand how we could attempt to
quantify this risk, but the data from the 2009 key rollover events, with a
far lower level of DNSSEC use was a significant cause for concern at the
time.

We would request the root zone operators to engage in some further
investigation of this, perhaps with a carefully controlled experiment that
could shed further light on the extent to which this proposed key roll
represents a serious risk to the integrity of operation of the DNS.

--

Geoff Huston, George Michaelson
APNIC







<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy