Internet Unknown (28)
kcd at daimlerchrysler.com
Thu Nov 18 23:08:04 UTC 2004
Jonathan de Boyne Pollard wrote:
>MA> The polaris.co.in nameservers are not RFC 1034 compliant (they don't
>MA> reply to EDNS (RFC 2671) queries).
>Not replying to queries is not a violation of the protocol. There's no
>way that any protocol (such as DNS) that employs an unreliable transport
>(such as UDP) can make replying to messages a requirement.
Way. Just because you can't make it requirement for the reply to be
*received* by the client, one can (and did, in this case) certainly make
it requirement for the reply to be *sent* by the server. The main caveat
here would be if the server is having capacity or other operational
problems, in which case it might be unable to get a reply out (but then
such edge cases are understood to be true of all servers serving all
>to say that a server that doesn't reply to queries is not complying with
>MA> You would think that all nameservers would handle EDNS queries by
>MA> now. After all EDNS has been on the standards track for 5 years now.
>The situation with EDNS0 is that because so few content DNS servers
>support it, the gain that EDNS0 gives from losing the DNS/TCP
>setup/teardown overhead in the small minority of cases is entirely
>offset by the loss incurred by the extra DNS/UDP traffic in the vast
>majority of cases.
>As I have said before, the irony of this is that support for EDNS0 in
>content DNS servers is comparatively easy compared to support for EDNS0
>in the back ends of resolving proxy DNS servers and in DNS Client
>libraries. If everyone merely did only the easy part of implementing
>EDNS0 support in their content DNS servers (even if only supporting
>DNS/UDP datagram sizes up to 512 octets), the current situation would be
>much improved, and enabling the use of EDNS0 in a resolving proxy DNS
>server would no longer result in a net increase in network traffic.
It's a critical-mass problem. Regardless of how easy or hard it is,
server software people would never see the benefit of adding EDNS0
support if there weren't resolvers actively trying to use it (especially
those server software authors <ahem> who never seem to want to change
their software *ever* because apparently they think it's perfect as-is),
but the resolver software people, for the most part, see no benefit in
adding EDNS0 support if there are few server implementations that
recognize it. You've got to start somewhere, and ISC/BIND has at least
gotten the ball rolling. It's an inefficient situation now, sure, but
it'll be more efficient in the long term.
More information about the bind-users