[dns-operations] hard data on signed, truncated priming queries

Paul Vixie vixie at isc.org
Tue Dec 15 00:05:10 UTC 2009


> Date: Mon, 14 Dec 2009 21:41:40 +0000
> From: bmanning at vacation.karoshi.com
> 
> 	about 14% of the priming queries that hit "B" set DO=1/BUFSIZ=512.
> 	presuming David Conrads public statement that the response size in
> 	their testbed was just under 1800 bytes leads me to project
> 	problems.

the difference between a "projection" and a "study" includes understanding
why those 512's are there, including in terms of whether they are falling
back, and from what, and why.  much of this traffic could disappear for
reasons not covered by a "projection" but not left out of a "study".

> 	Even Matts note about a response size of 800ish bytes would seem to
> 	be problematic - given the behaviours of middleboxen.

"seem to be" is not a term of art here.

> 	the "wild-card" here is fragmentation... what happens when EDNS is
> 	enabled and fragmentation occurs... Few middlebox devices seem to
> 	deal well with UDP fragments.

fragmentation has very little to do with the 512 case you're projecting
about.  we are all worried about fragmentation, but for reasons unrelated
to the number of DO=1/EDNS=512 queries we see in our traces.

> 	Then we have TCP as the failover... 

so this is just an old concern dressed up in unrelated nonsequitur clothing?

> ...
> 
> I posit three possible outcomes:
> 
> a) authoritative server operators take a hardline and ignore middlebox
> assumptions.
> 
> b) authoritative server operators take the pacifist line and jump through
> hoops to cram ... enough "correct" data into a 512byte UDP datagram 
> 
> c) we wait - again - for decent crypto to save us - According to
> Bellovin, we could prolly get by with EC in such a small package.

we're at "a" for now and have been for some time and this is not news.

> all of these have multiyear, long-tail failure modes.  a) pushes the cost
> to the edge, b) is a fundamental change in DNS behavour and pushes the
> cost to the core, and c) ... looks like DNSSEC over the last 18 years or
> so...
> 
> if you had to choose, where would you go?

we did have to choose, and we had to choose "a".  why are we still debating
as if any of these choices are still open or as if any of these concerns
were not painfully well known by the people who gave the nod to DNSSEC in
its current form for use in the root zone?



More information about the dns-operations mailing list