Operators, how do you handle EDNS?

[Mark Andrews]

In message <20090114000726.GA23033 at esri.com>, Ray Van Dolson writes:
> I know what ISC will say on this -- that we should be tracking down
> people whose DNS servers or network infrastructure blocks or impedes
> EDNS... this is fine and well, and we do make such efforts, but often
> times networ owners are unresponsive and our own customer demands
> compel us to disable EDNS support for certain DNS servers.
> 
> Over time this list has gotten large and we've been very tempted to
> disable EDNS completely with something like the following:
> 
>   server 0/0 { edns no; }; // Only valid in 9.4.x and newer
> 
> Does anyone out there actually do this?
> 
> We're currently running vendor supplied BIND (Sun) which is based on
> 9.3 so the above isn't currently an option.  But it's a pain to have to
> add in a bunch of IP's for Akamai, etc.  We would obviously like to be
> good netizens and assist with getting people compliant, but sometimes
> that just doesn't fit in with reality when you have people complaining.

	Akamai boxes respond to EDNS queries. If you are getting
	timeouts on Akamai boxes it's not due to EDNS. Named will
	make a plain DNS query when it gets a FORMERR response to
	a EDNS query.

 
> Even boeing.com (they block edns) who has an extremely low TTL on their
> A records (a few minutes) causes us problems.  By the time BIND has
> gone through querying each of their DNS servers and determined it needs
> to re-query without EDNS on the query time has taken a significant
> amount of time.  This wouldn't be a problem if their TTL was lower,
> but, this does pop up more often than not and users complain of delays
> in their lookups.

	boeing.com's nameservers respond to EDNS queries. If you
	are getting timeouts it's not due to EDNS.
 
% dig boeing.com soa +dnssec +norec @stldnsxp01.boeing.com.

; <<>> DiG 9.3.5-P2 <<>> boeing.com soa +dnssec +norec @stldnsxp01.boeing.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 31356
;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 223 msec
;; SERVER: 130.76.96.65#53(130.76.96.65)
;; WHEN: Wed Jan 14 11:25:16 2009
;; MSG SIZE  rcvd: 12

% dig boeing.com soa +dnssec +norec @stldnsxp01.boeing.com.

; <<>> DiG 9.3.5-P2 <<>> boeing.com soa +dnssec +norec @stldnsxp01.boeing.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 51850
;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 230 msec
;; SERVER: 130.76.96.65#53(130.76.96.65)
;; WHEN: Wed Jan 14 11:25:18 2009
;; MSG SIZE  rcvd: 12

% 

> I'd just like to hear some feedback from other sysadmins out there as
> to how you're dealing with EDNS.  Currently, we are leaning towards
> upgrading all of our BIND's and just disabling it completely with the
> syntax above...
> 
> Flames and comments more than welcome. :-)

	The number of nameservers that fail to respond to EDNS
	queries is miniscule.  The majority of nameservers on the
	net actually talk EDNS.

	I suggest that you re-analyse the failures to determine
	their true causes.

	Mark

> Ray
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org