Subject: [dnsext] Why the cause of drops matter...

From: Nicholas Weaver <[email-masked]>
Date: Fri, 19 Jun 2009 08:29:24 -0700

Netalyzr now (finally, sorry for not thinking of this earlier)  
distinguishes why a large EDNS-enabled response to an EDNS request  
fails: whether it is due to fragmentation not being reassembled  
(assuming the de-facto MTU of ~1500B) or due to a middlebox thinking  
DNS should be 512B.

	This is accomplished by having a lookup for edns_large return an  
~1800B response, and edns_medium return a ~1400B response.

	I do NOT have statistically significant numbers for this yet.

	This matters:

	If the problem is mostly fragmentation, DNSSEC signing authorities  
who don't want TCP fallback would benefit greatly from making sure  
responses <1500B, but its OK for them to be >512B.

	If the resolver maintains state about how an authority responds to  
EDNS, it SHOULD first fallback to 1400B, so that it can successfully  
get responses, and only if 1400B fails, fallback to 512B.  This is to  
enable the resolver to learn if the issue is fragmentation or if the  
issue is 512B, and act appropriately.

	If the resolver does NOT maintain state about how an authority  
responds to EDNS, it doesn't matter if the fallback is to 512B.  The  
condition will only occur if the response was greater than the MTU for  
the network, so a fallback to 1400B will probably not succeed.

	Thus since Bind does not maintain state about the authority, dropping  
to 512B is perfectly fine.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Fri, 19 Jun 2009 16:53:18 +0100

> to 512B is perfectly fine.

That's my conclusion too.  [ unless DO=1 ;-) ]

Ray

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 19 Jun 2009 09:50:05 -0700

> That's my conclusion too.  [ unless DO=1 ;-) ]

I'll argue that for DO=1, its still fine.

It will have to fall back to TCP because the result will be truncated,  
but it will have to fallback to TCP anyway.