[dns-operations] wrapup of fragmentation/do/tcp discussion requested

[Mark Andrews]

In message <9BB6F4B8-9EF6-4B20-B26D-8768A155515A at virtualized.org>, David Conrad 
writes:
> Bert,
> 
> On Jun 21, 2009, at 3:49 AM, bert hubert wrote:
> > It also appears BIND is now asked to drop the DO ('DNSSEC ok') bit  
> > if it
> > can't get a clear UDP based path to the ORG servers large enough to  
> > carry
> > signed answers.
> 
> No.  The problem is that BIND's (and others?) EDNS0 probing heuristic  
> tries the following:
> 
> 1. Try EDNS0 with bufsize=4069 and DO=1
> 2. if this fails or times out then try EDNS0 with bufsize=512 and DO=1
> 3. if this fails or times out, then try without EDNS0
> 
> Step 2 results in a response with DNSSEC-related RRs which response  
> will likely be over 512 bytes, thus triggering fallback to TCP.  Step  
> 2 is also a clear violation of RFC 3226.  If you ignore the intent of  
> 4035, one can argue that it isn't a violation of that RFC.
> 
> My understanding (and I'm sure Mark will correct me if I'm wrong) is  
> that the reason for the fallback to 512 bytes is that some DNSSEC- 
> related RR containing responses will actually fit in 512 bytes, thus  
> falling back to 512 allows for more cases in which DNSSEC can be  
> validated.

	1.  512 covers all the recoverable failure paths.
	2.  512 doesn't significantly change the amount of fallback to
	    TCP due to fragmentation/DNS proxies.
	3.  Some answer are less that 512 bytes in size.
	4.  The relative numbers of firewalls that actually block EDNS
	    traffic larger than 512 bytes is small.
	5.  Not everyone is in a position to change the equipment that
	    is blocking the responses to 4096 byte queries.
 
> Perhaps we're looking at this wrong.  Maybe (and I haven't given this  
> much thought) a better approach would be to start off with an  
> advertised buffer of 512 and if TC is going to be set, the server  
> returns the amount of space the response will require, letting the  
> client make the decision to retry with a larger buffer size  
> (corresponding to what the server said would be needed) or with TCP?

	That would cause a lot more traffic.  Most EDNS queries get
	answered without any fallback at all occuring.
 
> > In other words, DNSSEC over TCP appears not to be acceptable?
> 
> DNSSEC over TCP is always acceptable (or should be), albeit it should  
> be avoided if possible due to the increased load it places on  
> authoritative servers.  In most cases, that additional load is  
> irrelevant.  However, in the case of the root servers, it is a bit  
> worrisome.
 
	I don't see how the roots can avoid all TCP especially if
	they need to use RFC 5011 key rollover techniques.  The
	only question is how much TCP there will be and whether 512
	byte firewalls add too much.  No fragment firewall and DNS
	proxies will cause some TCP to happen.

> > Or alternatively, people w/o a path that supports framents to
> > the auth servers, should do w/o DNSSEC too?

	No one is saying that.  Some are say tough #@%$@!# to those
	that only have a 512 byte path, you can't do DNSSEC because
	we fear that you will overload the high level authoritative
	servers.  I see no evidence of that occuring.

	No one is asking for all paths to support fragmentation.

> It isn't a question of DNSSEC, it's a question of EDNS0 advertising a  
> buffer size that will result in fragments and whether the Internet  
> sucks so badly for fragments to make that problematic.  If there is a  
> path that doesn't support fragments, folks are going to run into  
> challenges unrelated to DNSSEC (e.g., referrals from the root are  
> larger than 512 due to the inclusion of IPv6 records).

	IPv6 alone is unlikely to result in fragmentation occuring. I
	IPv6 address is only 28 bytes additional bytes on the wire.
 
> Regards,
> -drc
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org