Maintained by: NLnet Labs

[Unbound-users] Cascading Unbound and automatic key update

lst_hoe02 at kwsoft.de
Tue Jan 10 16:56:36 CET 2012


Zitat von "W.C.A. Wijngaards" <wouter at nlnetlabs.nl>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Andreas,
>
> On 01/10/2012 03:43 PM, lst_hoe02 at kwsoft.de 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