[Unbound-users] Cascading Unbound and automatic key update
lst_hoe02 at kwsoft.de
lst_hoe02 at kwsoft.de
Tue Jan 10 15:56:36 UTC 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:
>> 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
> 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
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?
More information about the Unbound-users