Operators, how do you handle EDNS?

Ray Van Dolson rvandolson at esri.com
Wed Jan 14 00:07:34 UTC 2009


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.

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.

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. :-)

Ray



More information about the bind-users mailing list