Francis,
On Aug 20, 2008, at 3:17 PM, Francis Dupont wrote:
as you know the DO bit means DNSSEC RRs are accepted, so an
implementation which supports them should set the DO bit.
Mumble.
So, DO=1 by default will result in DNSSEC-related RRs being returned,
regardless of whether those RRs will actually be used. What my intent
was with 3225 is no longer particularly relevant since shipping code
has been doing this for quite some time.
The implication of this is that the day the root gets signed, the root
servers will be responding with DNSSEC-related RRs, regardless of
whether caching servers intend on doing anything with them. This
raises a few potential operational issues:
- if the advertised EDNS0 buffer size is not large enough, it will
trigger truncation and, as a result, an increase in the number of TCP
sessions going to the root.
- if the advertised EDNS0 buffer size is large enough, but the network
MTU is too small, fragmentation will occur which may cause the
response to be dropped (for a variety of reasons).
- if there are middle boxes in the way that do stupid things (e.g.,
disallow DNS over TCP), those middle boxes will likely drop the larger
responses.
The concern I see (that I had hoped would be avoided by DO being set
to 1 only when the caching server administrator had explicitly
configured DNSSEC awareness) is that folks who are blissfully unaware
of the root being signed would, through no fault or action on their
part, could begin to see odd DNS failures due to one of the three
issues I mention above.
In any event, I have an answer to my question...
Regards,
-drc
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
