--On 13 January 2010 21:16:49 +0000 Jim Reid <j...@rfc1035.com> wrote:
On 13 Jan 2010, at 20:49, Alex Bligh wrote:
Current operational practice would result in DO clear packets
fitting within 4096 bytes, so no need for TCP when DO is clear.
I don't think that's always the case Alex. See the lengthy discussion in
this list about datagram fragmentation and broken middleware boxes that
don't grok EDNS0. [Or do EDNS0 with a 512 byte buffer size. Sigh.] Mind
you, some of those boxes will also barf on TCP DNS traffic.
Indeed - my slack language. I meant that UDP should at least be given a
go as we don't know a priori that it will fail. We pretty much do know
that for a DO set query.
The preferred approach might probably be along these lines:
[1] EDNS0 + DO with a buffer of 5-8K (ish)
[2] TCP + DO when [1] fails
[3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails
[4] EDNS0 (no DO) with a 1.5K (ish) buffer
[5] Vanilla UDP (no EDNS0) if [4] fails
I think it would be helpful if the guidance on priming queries was split
into 3 categories: resolvers that speak DNSSEC, those that are not
DNSSEC-aware but speak EDNS0 and resolvers that are ignorant of both
protocols. They'd start at [1], [4] and [5] respectively in the scenario
above. The optimal priming behaviour for each may well be different,
particularly wrt EDNS0 buffer minima and maxima. It would be good to give
an explanation for those buffer sizes too in case we've all forgotten
about that when revisiting the issue 5-10 years from now.
You've eliminated TCP fallback for non-DNSSEC supporting clients. On
e.g. small MTU dialup, (4) will not succeed in certain circumstances
(i.e. where fragments are not transmitted correctly). I think here
you are relying on [5] to work, but it seems to me reasonable for
a well behaved (but not DNSSEC supporting) client to make a TCP query
if UDP doesn't get through for whatever reason.
Perhaps the recommended resolver behaviour should apply to all queries
and not just the priming query?
This is somewhat swimming against the tide of (e.g.)
draft-ietf-dnsext-dns-tcp-requirements and
draft-bellis-dns-recursive-discovery (unadopted, disclosure: am coauthor),
which each take the view that there's enough middlebox and fragmentation
breakage of UDP that TCP should be available as a reliable fallback.
Sure, clients should as a general rule try getting UDP to work, but
I think preventing them falling back to UDP unless they are prepared
to take the overhead of adding DO set is not right. It might have
the perverse effect of encouraging people to set DO unnecessarily.
--
Alex Bligh
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
