[Unbound-users] Unbound stop working without error-log
lst_hoe02 at kwsoft.de
lst_hoe02 at kwsoft.de
Thu Dec 2 11:28:57 UTC 2010
Zitat von lst_hoe02 at kwsoft.de:
> Zitat von "W.C.A. Wijngaards" <wouter at NLnetLabs.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Hi Andreas,
>> On 11/03/2010 09:07 AM, lst_hoe02 at kwsoft.de wrote:
>>> It seems more that unbound and bind disagree in their opinion if the
>>> signature is expired or not. As said the time unbound starts failing the
>>> same queries done directly to the upstream resolve *and* validate fine.
>>> So the options are:
>> That is strange. Your clocks are synchronised, so that is not it.
>> Could it have been the recent daylight-savings change somehow?
>> Both bind and unbound may have some leeway for expired signatures that
>> you can configure; val-sig-skew-max and val-sig-skew-min config options
>> for unbound.
>>> - Bind does not send the same data it is using for validation to the
>>> downtsream (unbound) client. Would be a Bind bug i guess.
>> Try doing a dig @<bind> name +dnssec and then with +dnssec +cdflag. If
>> that is different, then this is happening.
>>> - Unbound and Bind do validation different (should not happen IMHO)
>>> - Validation in Unbound for some cases is broken. Would be a bug in
>>> Unbound i guess.
>> Well, when unbound refuses to validate it, enable val-log-level: 2, and
>> take a look in the log file, it gives a detailed error. Then dig
>> +dnssec and dig +dnssec +cdflag when it mentions (also to the unbound so
>> see what is in the cache, and also at the IP address it mentions).
>> If you enable val-log-level: 2 (and you can have verbosity low), it
>> gives one line per validation failure. This is a (relatively) low
>> amount of logging, but very useful, as it tells you why exactly unbound
>> failed the query.
>>> It would be nice to get help how to debug this as DNSSEC "by-hand" is
>>> somewhat challenging.
>> This is pretty easy, the RRSIG notes ....
>> RRSIG bla bla expiration inception bla bla.
>> They are in yyyymmddhhmmss format UTC.
>> Most signers leave a couple weeks headroom in the expiration date.
> I will try to capture the follwoing:
> - Logging from unbound as suggested
> - dig from both as the error happens
> - Packet dump from unbound <--> bind communication over the wire
I was not able to reproduce the problem any more but maybe it was even
related to that one:
Fix for Bind 9.7.2-P3:
It was discovered that Bind would incorrectly mark zone data as insecure
when the zone is undergoing a key algorithm rollover. (CVE-2010-3614)
More information about the Unbound-users