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 : sval...@genoscope.cns.fr
Simon Vallet <sval...@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.
> On Fri, 25 Jan 2008 16:11:19 +0100 > Simon Vallet <sval...@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
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.
Mark Andrews <Mark_Andr...@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.
> On Sat, 26 Jan 2008 10:22:05 +1100 > Mark Andrews <Mark_Andr...@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.
Sounds reasonable.
> Thanks for the tip, though > Simon
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andr...@isc.org
> > On Fri, 25 Jan 2008 16:11:19 +0100 > > Simon Vallet <sval...@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
> 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.
> 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_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?
"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!"
