[dns-operations] "Going dark" claims

[bmanning at vacation.karoshi.com]

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


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

	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.  Glad to have real, emperical
	data from you as to what the actual size will be.  801 bytes will
	certainly be easier to digest - or not based on Ray's numbers.
	(see SSAC35) 

	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.

	wrt a) - this could be done in something less than a six month gradual
	deployment ...  which leaves b).   now the phased rollout of the DURZ
	might just illluminate the extent of the problem ...  and if it turns
	out to be "significant" - what are the options for the community?

	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.

	If my participating in public discourse makes  you uncomfortable, I will
	be glad to sit back and watch how you manage this transition.  

	Thank you for your time.

--bill