Operators, how do you handle EDNS?
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Operators, how do you handle EDNS?
On Tue, Jan 13, 2009 at 04:35:46PM -0800, Mark Andrews wrote: 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 I'd thought we'd ruled this out, but testing again from an OOB server confirms what you're saying. Will definitely reinvestigate. Initially I am getting these in response to my dig queries: # dig @130.76.96.65 boeing.com soa +dnssec +norec ;; Warning: ID mismatch: expected ID 1582, got 13152 ;; Warning: ID mismatch: expected ID 1582, got 13152 ;; Warning: ID mismatch: expected ID 1582, got 13152 ; DiG 9.3.5-P2 @130.76.96.65 boeing.com soa +dnssec +norec ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached I guess our firewall could be tinkering with the request ID's? Perhaps as a result of dnssec being on... hmm. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Operators, how do you handle EDNS?
In message 20090114021016.ga24...@esri.com, Ray Van Dolson writes: On Tue, Jan 13, 2009 at 05:00:38PM -0800, Ray Van Dolson wrote: On Tue, Jan 13, 2009 at 04:35:46PM -0800, Mark Andrews wrote: 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 I'd thought we'd ruled this out, but testing again from an OOB server confirms what you're saying. Will definitely reinvestigate. Initially I am getting these in response to my dig queries: # dig @130.76.96.65 boeing.com soa +dnssec +norec ;; Warning: ID mismatch: expected ID 1582, got 13152 ;; Warning: ID mismatch: expected ID 1582, got 13152 ;; Warning: ID mismatch: expected ID 1582, got 13152 ; DiG 9.3.5-P2 @130.76.96.65 boeing.com soa +dnssec +norec ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached I guess our firewall could be tinkering with the request ID's? Perhaps as a result of dnssec being on... hmm. Thanks Mark. Alright, I believe the DNS Scrambling feature of our firewall could be causing the issue -- that or scrambling on boeing.com's end. Maybe someone can comment... It seems that the transaction ID's are being changed and so the Format Error packets coming back from boeing are dropped by BIND. This is why I see BIND cycling through all their nameservers -- the query timeout is being triggered. If the transaction ID's matched correctly, the Format Error would be processed and the query would be retransmitted without EDNS correctly. What I'm trying to figure out is if this is a result of scrambling on *our* end, the remote end or a combination of both. Clearly the vast majority of our queries succeed, but I don't know how exactly our CheckPoint firewall decides to do its scrambling magic, and, of course no clue on the remote end. Anyone have any thoughts to add? 100% your end. Ray ___ bind-users mailing list bind-users@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_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
