Zitat von "W.C.A. Wijngaards" <[email protected]>:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andreas,

On 01/10/2012 03:43 PM, [email protected] wrote:
Hello

we have a internal unbound cache using a second unbound instance at
the border firewall to do dns resolution with DNSSEC enabled. Today
our internal unbound stop working with errors like this:

Jan 10 14:33:53 mailer unbound: [27958:0] info: validation failure
<www.at-web.de. A IN>: no DNSSEC records from x.x.x.x for DS
at-web.de. while building chain of trust Jan 10 14:33:53 mailer
unbound: [27958:0] info: validation failure <www.heise.de. A IN>:
no DNSSEC records from x.x.x.x for DS heise.de. while building
chain of trust

So, what it looked like for this server was that dig @x.x.x.x DS
heise.de +dnssec +norec +cdflag did not return any DNSSEC data.

As if there were fragmentation problems.  And since it was internal
there are extra firewalls or routers for that sort of thing to occur.

The instance at the border firewall has no errors in the log and
works fine all the time. After restarting the internal instance, it
is also working fine again. The auto-trust-anchor-file of the
internal instance has a timestamp from the restart of the instance,
so i suspect something went wrong with the update of this file, but
i have no glue why the restart cured it.

No, the timestamp was probably written right when you restart it.
Because it is written when the root DNSKEY is seen.  When you restart
it the cache is empty and it fetches the root DNSKEY.  And thus
updates the file to note that it saw the root key.


Both instances are Unbound version 1.4.14 with auto-trust-anchor
enabled. The forwarding from internal to firewall instance is done
this way:

forward-zone: name: "." forward-addr: x.x.x.x

This looks fine.

What can we do to debug this problem and prevent it from happening
again?

There is something happening with UDP.  There seems nothing wrong with
key files.  The error is that somehow it gets no DNSSEC data (edns
backoff, or messages arrive 'stripped' of DNSSEC data).

Would it be smart to set

module-config: "iterator"

at the internal unbound cache and do i need to set "ignore-cd-flag: yes" at the firewall to let the border unbound do all validation?

This should prevent this kind of error in any case, no?

Many Thanks

Andreas


_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

Reply via email to