Too many timeouts resolving / disabling EDNS messages

[Simon Vallet]

Hi,

having recently upgraded one of our nameservers to 9.5.0b1, we now get
the following into our logs :

too many timeouts resolving 'example.com MX'; disabling EDNS

Digging a little bit shows that BIND now queries every host using EDNS0,
even if dnssec-validation or dnssec-enable is off, which seems overkill.

We get *lots* of messages like this, and even if I know we can prevent
BIND to log these, I'd much rather disable EDNS queries alltogether.
But as I understand it, this is currently not possible -- any particular
reasons for this ?

Simon

--
Simon Vallet
Ingénieur Systèmes/Réseaux
CEA DSV IG / Genoscope
Tél. : 01 60 87 36 06
E-mail : sva...@genoscope.cns.fr

[Simon Vallet]

On Fri, 25 Jan 2008 16:11:19 +0100
Simon Vallet <sva...@genoscope.cns.fr> wrote:

> Digging a little bit shows that BIND now queries every host using EDNS0,
> even if dnssec-validation or dnssec-enable is off, which seems overkill.

OK -- digging a little bit more shows that this has actually been
standard behaviour for some time now. So the better solution is
probably to disable logging of these messages.

Sorry for the noise,
Simon

[Mark Andrews]

The better solution is to work out if it is a local problem
that is causing the messages and fix it.

The usual causes is a broken or misconfigure firewall / NAT.

* A Firewall that doesn't allow through DNS packets > 512 bytes.
* A Firewall/NAT that doesn't allow IP fragments through.

To workaround either of these set edns-udp-size to a
appropriate value but only do it if you can't fix the
underlying problem.

e.g.
I've got a NAT that can't handle out-of-order IP
fragments so I use "edns-udp-size 1460;" which is
small enough so that a UDP packet will fit in a
Ethernet packet without fragmentation provided no
IP options are set.

"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.

I don't have a out-of-order IP fragmentation test.

These messages are rare events with a EDNS clear path.

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

[Simon Vallet]

On Sat, 26 Jan 2008 10:22:05 +1100
Mark Andrews <Mark_A...@isc.org> wrote:

> The better solution is to work out if it is a local problem
> that is causing the messages and fix it.

Yep. That's what I was thinking at first -- but our firewall is fine :
it seems the problem is at the other end of the path, which are mostly
spam domains, to which we are (sadly) still delivering DSNs.

So the situation will probably be a lot better once the legacy mail
infrastructure has morphed into an acceptable shape -- something that
should be ready soon :-) Then it will be the time to log those messages
again.

Thanks for the tip, though
Simon

[Mark Andrews]

Sounds reasonable.

> Thanks for the tip, though
> Simon

[spaav]

> PHONE: +61 2 9871 4742 INTERNET: Mark_Andr...@isc.org

I've been getting the EDNS timeouts as well using bind 9.5. EDNS
doesn't appear to work at all for me. Thanks for these suggestions
using dig. I'd previously tried to fix my firewall, but these dig
commands indicate my firewall is working ok. Do you have anything else
I could try to resolve my problem?

Steve

[l...@dr.com]

Solution:

add the following lines in /etc/named.conf or /var/named/chroot/etc/
named.conf:

logging {
category lame-servers {null; };
category edns-disabled { null; };
};

Hope to help ...

Antonio Carlos de Lima
------------

"You know, evil comes in many forms, be it a man-eating cow or Joseph
Stalin. But you can't let the package hide the pudding. Evil is just
plain bad. You don't cotton to it. You gotta smack it on the nose with
the rolled up newspaper of goodness. Bad dog! Bad dog!"