Internet Unknown (28)

[Mark Andrews]

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

	To not reply when you receive a query you don't understand is
	a violation of the protocol.  RFC 1034 includes error code to
	tell the client that you don't understand the query.  A server
	is supposed to use them.  To not use them is a violation of
	the protocol.

	From 1034
	NOTIMP is required to be sent when you get a opcode you don't
	support.
	FORMERR for when you get a query that doesn't appear to be correct.
	REFUSED is for when you are blocking answers for administative
	reasons.
	SERVFAIL is the fallback error code.

	A RFC 1034 compliant server should send FORMERR in reply to
	a EDNS query.  In practice some send NOTIMP and SERVFAIL or
	just ignore the EDNS extention and just a plain DNS answer.

	Then you have the servers that drop EDNS queries and for
	kicks there is a vendor that refuses to answer future queries
	for ~30 seconds after receiving a EDNS query so lookups
	fail even after fallback to DNS on timeout.

> 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.
> 
> MA> It only takes 1/2 a day to add support for them to a existing
> MA> server.
> 
> That's a facile assertion.  How long it takes to add EDNS0 support 
> obviously depends from the particular server software.  As I said, it 
> also depends from the type of the server software.

	If you are capable of writing a DNS server the work required to
	implement and test EDNS support is about 1/2 a day.  It is much
	less in authoritative only servers.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org