> 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.
These are basically EDNS problems and will be happening
today, as the root servers are EDNS capable, to a lesser
or greater extent.
Any of the clients that make queries from any of the already
signed TLD's will have experienced the same issues. None
of this is new.
You are not the first major player to sign. You are the
one major player that every talks to.
Caches will cope with all of the above. There may be some
retries. The retries will be logged by some caches. The
broken middle boxes will get fixed/replaced.
Vendors will ship less cr*pware initially as the result of
the root being signed as their in house tests will have a
higher probability of detecting the damage their products
are doing.
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
