[dns-operations] "Going dark" claims

[Matt Larson]

On Mon, 14 Dec 2009, bert hubert wrote:
> On Mon, Dec 14, 2009 at 12:25:49AM +0100, Peter Koch wrote:
> > my point is that the "melody" of the message is very important. Nothing in
> > this very good article really rings an alarm bell or "warns" people.
> > It is "just" good technical information.  The hard part is to tailor
> > the message towards the intended or even anticipated target audiences.
> > I'm all for openness and advance announcements, but some of the postings
> > in this thread could be read to suggest we're going to face a big experiment
> > with zillions of innocent victims being cut off the net.
> 
> This is in fact what one root operator says, so it goes way beyond
> 'suggesting'.
> 
> As bmanning said:
> 
> 	from my limited scope testing (from one root) there are
> 	double-digit percentage of priming queries that will get
> 	hit with this problem... I think parts of the internet
> 	will go dark. 
> 
> https://lists.dns-oarc.net/pipermail/dns-operations/2009-December/004760.html
> 
> So it is't the actual tone of the message that is worrying, it is also the
> music itself.
> 
> Or is bill wrong? Because a root-priming query with EDNS enabled has been
> returning >512 answers for a long time now. Or perhaps BIND doesn't do that?

Bill is making this claim but I have not heard any reasoning to back
it up.

Indeed, the current priming response 643 bytes, but still fits
gracefully into 512 bytes: there is room for at least 10 root server A
RRs and at least two AAAA RRs in the additional section.  So based on
such a 512-byte priming response, an iterative resolver has plenty of
root server IPv4 and IPv6 addresses to work with to resolve the
remaining root server IP addresses.

The priming response from the impending signed root will be 801 bytes.
The only difference between that response and today's is the addition
of an RSSIG(NS) at the end of the authority section.  When fit into
512 bytes, the future priming response still contains five A RRs and
one AAAA RR in the additional section.  Not ideal, but still plenty
for an iterative resolver to work with.

Bill, I would respectfully suggest that you please either explain your
reasoning or stop making these "go dark" claims.  You are on the verge
of yelling "fire!" in a crowded theater.

Matt