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

David Conrad drc at virtualized.org
Sun Jun 21 16:55:06 UTC 2009


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.

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?

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

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

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

Regards,
-drc




More information about the dns-operations mailing list