SERVFAIL on added KSK (DNSSEC) without reload of unbound

[Peter Larsen]

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