disableing EDNS messages bind-9.5.0

[Danny Thomas]

Dean Clapper wrote:
> I'm trying to troubleshoot why we are getting a lot of disabling EDNS 
> messages in /var/log/messages.
>
> We are running bind-9.5.0.P2 on a linux box.
>
> Jan 27 11:42:23 ns0 named[27764]: too many timeouts resolving 
> 'host2.centmine.com/AAAA' (in 'centmine.com'?): disabling EDNS
> Jan 27 11:42:24 ns0 named[27764]: too many timeouts resolving 
> 'host1.centmine.com/AAAA' (in 'centmine.com'?): disabling EDNS
> Jan 27 11:42:38 ns0 named[27764]: too many timeouts resolving 
> 'pts1.abovecow.com/AAAA' (in 'abovecow.com'?): disabling EDNS
> Jan 27 11:42:38 ns0 named[27764]: too many timeouts resolving 
> 'pts2.abovecow.com/AAAA' (in 'abovecow.com'?): disabling EDNS
> ...
> Jan 27 11:43:39 ns0 named[27764]: too many timeouts resolving 
> '196.198.117.216.zen.spamhaus.org/A' (in 'zen.spamhaus.org'?): 
> disabling EDNS
>
> I started receiving these messages after updating from 9.4 -> 9.5. 
> I've found a couple places to test packet sizes, but have not had any 
> problem. The messages about zen.spamhaus.org leads me to possibly 
> email related issues.
googling "disabling EDNS" would have been a start

anyway
add "category edns-disabled { null; };"
after verifying your nameserver(s) have an EDNS0 clear path
by trying the 2 tests mentioned below by Mark Andrews.

here's the comment from our named.conf template

We were somewhat concerned when seeing lots of these messages with 9.5:
edns-disabled: info: too many timeouts resolving '<query>'
The description in ARM:
This is often due to the remote servers not being RFC 1034 compliant (not
always returning FORMERR or similar to EDNS queries and other extensions
to the DNS when they are not understood). In other words, this is targeted
at servers that fail to respond to DNS queries that they don’t understand.

Note: the log message can also be due to packet loss. Before reporting 
servers
for non-RFC 1034 compliance they should be re-tested to determine the nature
of the non-compliance. This testing should prevent or reduce the number of
false-positive reports.

Note: eventually named will have to stop treating such timeouts as due to
RFC 1034 non compliance and start treating it as plain packet loss. Falsely
classifying packet loss as due to RFC 1034 non compliance impacts on DNSSEC
validation which requires EDNS for the DNSSEC records to be returned.

The following link
http://groups.google.com/group/comp.protocols.dns.bind/browse_thread/thread/cfa8c63ec6bd08d6
describes cases when EDNS is being blocked
* A Firewall that doesn't allow through DNS packets > 512 bytes.
* A Firewall/NAT that doesn't allow IP fragments through.
"dig +norec +dnssec example.com @a.root-servers.net"
Can be used to test if you firewall supports packets > 512.
"dig +dnssec +norec +ignore dnskey se @A.NS.se"
Can be used to test if IP fragments can get though at all.
The last sentence in Mark's message doesn't correspond to my experience:
These messages are rare events with a EDNS clear path
as I manually checked around 20 of these logged queries and found that 
nearly
all resulted in dig reporting "no servers could be reached". The messages
appeared in 9.5 because it always tries EDNS but I think they mostly come
from lame delegations (those 2 EDNS0 tests went OK).


Danny