SERVFAIL on added KSK (DNSSEC) without reload of unbound
peter.larsen at larsendata.dk
Wed Aug 21 11:38:05 UTC 2019
alright, perfect ;)
thanks for the good answer
> On 21 Aug 2019, at 12.37, Wouter Wijngaards via Unbound-users <unbound-users at nlnetlabs.nl> wrote:
> Hi Peter,
> Yes the resolver is supposed to cache the KSK and ZSKs with the TTL that
> they have. This is the supposed functionality of DNSSEC, eg. resolvers
> cache the date for their TTL and it remains valid for that time.
> If you enter new keys and use them without waiting for the TTL(s) to
> expire, it won't work. There are several drafts, RFCs and documents on
> the matter. Called rollover timeout schedules, and similar, usually
> also try to factor in the time it takes for the data to propagate
> through the publication system, secondaries and so on.
> If you add a new key and try to use it without waiting for the DNSKEY
> rrset TTL to expire, it won't be there in all caches, and the test you
> set up simulates this. Also, before you can remove a key, you have to
> wait for all the signatures with it to be gone and their TTL to expire,
> and for KSKs for the DS record to be gone and its TTL to expire. There
> are tables for action sequences and formulas to calculate the timers, in
> advice documents.
> You can get unbound to print a summary of the validation failure with
> val-log-level: 2 , in this case, I think, just that it cannot find the
> right key, because it was not there when the key lookup happened.
> Best regards, Wouter
> On 21/08/2019 12:18, Peter Larsen via Unbound-users wrote:
regards, Peter Larsen
More information about the Unbound-users