[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt
--On 28 October 2009 08:25:48 +0000 George Barwood
<george.barwood@blueyonder.co.uk> wrote:
If TCP is required, it seems logical to limit UDP responses to the
original size and deprecate the EDNS response buffer size mechanism.
I'm not sure if this is Ray's intention, but I think I agree with this.
I very much hope it isn't Ray's intention. That would be to use a
sledge-hammer to crack a nut, though that metaphor perhaps does not
encompass sufficient collateral damage.
You are advocating preventing UDP packets with a payload greater than 512
bytes. For those worried about TCP loading, this would increase it hugely,
as any client compliant with your recommendations would end up making a TCP
request just in case the response didn't fit into a 512 byte UDP payload.
This is quite apart from the fact that there is a huge volume of
EDNS0-supporting clients out there which will continue to make EDNS0
queries, so the deprecation as such will have little effect.
Where UDP works, there is no issue in using it. UDP is in the vast majority
of cases totally unproblematic, it seems to me, for communication between
caching resolver and authoritative server, and EDNS0 works just fine, even
above 1500 bytes, as people in general don't have firewalls et al. in the
way. The problem would appear to be in a small minority of those cases
(generally where the caching resolver is itself behind some form of
defective proxy), plus a significant portion of communication between stub
resolver and caching proxy. proxy-bypass will I hope go a little way to
alleviate the latter problem, but it won't cure it totally. TCP support
(possibly combined with proxy-bypass) will, I think, address the vast
majority of the cases.
--
Alex Bligh