[Unbound-users] Unbound stop working without error-log

[lst_hoe02 at kwsoft.de]

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)
>>
>> Yes.
>>
>>> - 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)

Regards

Andreas