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

[bmanning at vacation.karoshi.com]

On Mon, Dec 14, 2009 at 02:53:21PM -0600, Jorge Amodio wrote:
> > Your earlier message to this list said a double-digit percentage of the
> > priming queries that go to B will hit truncation problems if/when the server
> > gets the signed root. Now you're saying this finding is based on
> > *projections* from traffic analysis from an ICANN root server testbed. Can
> > you please help to clear up my confusion by answering the following
> > questions?
> >
> > [1] Where has this data and analysis been published?
> 
> There is some information  and analysis at
> https://st.icann.org/data/workspaces/new-gtld-overarching-issues/attachments/security_and_stability_root_zone_scaling:20091007230946-0-13722/original/root-zone-augementation-analysis-17sep09-en.pdf
> 
> Chapter 6.
> 
> Jorge.
> _______________________________________________

Jorge/Jim,
	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.

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

	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.

	Then we have TCP as the failover... 

my short list...


http://labs.ripe.net/content/preparing-k-root-signed-root-zone
http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
http://www.sanog.org/resources/sanog14/sanog14-gaurab-edns.pdf
http://www.icann.org/en/committees/security/sac035.pd
https://www.dns-oarc.net/oarc/services/replysizetest
https://st.icann.org/data/workspaces/new-gtld-overarching-issues/attachments/security_and_stability_root_zone_scaling:20091007230946-0-13722/original/root-zone-augementation/analysis-17sep09-en.pdf
https://www.dns-oarc.net/files/workshop-200911/Duane_Wessels.pdf

and the aformentioned SSAC35 report.

clearly some people think there are real issues but either want to make light of them or
presume that tweeks at one side or the other is going to work...  


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
	the 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.


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?

--bill