9.6.1-P1 log message
cet1 at cam.ac.uk
Mon Aug 31 16:59:00 UTC 2009
On Aug 26 2009, Mark Andrews wrote:
>In message <alpine.LFD.2.01.0908250838190.14151 at maplepark.com>,
>David Forrest writes:
>> What do I have to do to correct whatever is causing this log message from
>> named (9.6.1-P1-RedHat-9.6.1-4.P1.fc11)?
>> validating @0x7f9f2c60c200: dns1.registeredsite.com.dlv.isc.org DS: must be s
>> ecure failure
>This is ususally because named has fallen back to plain DNS. Please
>ensure that you have a clean EDNS path and any forwarders you use
>also have clean EDNS paths.
>A clean EDNS path will accept EDNS responses upto 4096 bytes in
>size. Firewalls and DNS proxies in SOHO routers are known devices
>which interfere with this. Sometimes intentionally (firewalls) and
>some unintentionally (SOHO routers).
>Firewalls must be configured to accept DNS responses bigger than
>512 bytes. They and SOHO routers also need to handle fragmented
>A flakey link can also cause fallback to plain EDNS when too many
>The dlv namespace is marked as "must-be-secure" by named as a side
>effect of dnssec-lookaside clause.
We have been running two production recursive nameservers validating against
dlv.isc.org since 9 June, and first saw a batch of messages (for both servers)
like this on 20 July. We reported them to ISC and got suggestions along the
lines of Mark's above, along with an admission that current versions of BIND
give up on EDNS too easily in situations they maybe shouldn't, which may be
fixed in future releases.
Since then we have had a trickle of such warning messages in the logs. We
assume that they are the result of temporary network glitches somewhere,
but their frequency appears to be increasing, which is somewhat worrying.
It's also not clear whether any client queries are actually failing as a
result, or whether BIND is simply trying another dlv.isc.org nameserver
with better luck.
Email: cet1 at cam.ac.uk
More information about the bind-users