[dns-operations] wrapup of fragmentation/do/tcp discussion requested
drc at virtualized.org
Sun Jun 21 16:55:06 UTC 2009
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
> 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
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
> 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).
More information about the dns-operations