[dns-operations] "Going dark" claims

[Matt Larson]

On Mon, 14 Dec 2009, Bill Manning wrote:
> On Mon, Dec 14, 2009 at 09:59:30AM -0500, Matt Larson wrote:
> > 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.

Bill,

> 	could you clarify how 643 bytes fits "gracefully" into 512 bytes?
> 	are you using Terrells Tribit scheme?

I believe you know exactly what I mean, given your understanding of
the DNS protocol and my explanation above, so I don't see any reason
for your comment, but I will humor you.

To be excruciatingly clear, by "fits gracefully" I meant that when a
priming response intended to be 643 bytes is truncated (in the
non-TC-bit sense of the term) to 512 bytes, the response still
contains a sufficient amount of data to be useful to an interative
resolver, i.e., there is still much information left in the additional
section in the form of A and AAAA RRs corresponding to name servers.

> 	the data I was using to project forward was based on the public 
> 	data provided by ICANN from their root server testbed...  where
> 	the response was closer to 1800 bytes.

ICANN's signed root test bed was good work.  It did not, however,
reflect the eventual signed root in at least one way: the zone apex NS
RRset was changed from [a-m].root-servers.net to another set of
servers, which allowed the signed zone to be actually used for
resolution.

> 	my concerns about response size seem to be reflected in the 
> 	current DNSSEC rollout plan for the root - why else would there 
> 	be all the trouble to deploy a DURZ?  There are only two reasons
> 	to deploy DNSSEC that can't be validated:  a) can the authoritative
> 	servers load signed data, and b) test for the impact of large
> 	response size while still allowing for the possibility of backing
> 	out.

You, of course, know that the reason is (b), since as a root operator
you've been briefed about the plan and have engaged in private
discussions about it.

> 	I'm hoping there will be a better dialog on choices to cope with
> 	fragmentation, TCP failover, and DO=1/BUFSIZ=512 behaviours between
> 	authoritative servers and resolvers.  If thats yelling "fire" - so be it.

The preceding paragraph's request for dialog is materially different
than "go dark" claims presented without supporting data or reasoning.
The closest I've seen you come to that is your recent reply to David
Conrad in this thread:

        its not really a bind issue - its more of a middlebox issue.
        SSAC35 talks to this issue in some detail.  and part of the reason
        we don't see this already is that the responses that are >512 are not
        priming queries - so the requestor gets -some- data back.
        then there is the whole question of what to do with UDP fragmentation...

Please, don't make me and everyone else solve the puzzle and fill in
the blanks to figure out what you're talking about.  If you are aware
of a problem or suspect a problem, please describe in clearly so we
can all understand it and engage in a constructive discussion.  So far
you haven't given us enough to do that.

Matt