Internet Unknown (28)

[Kevin Darcy]

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 
network protocols).

>It's wrong 
>to say that a server that doesn't reply to queries is not complying with 
>RFC 1034.
>
>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.

- Kevin