alright, perfect ;) thanks for the good answer
> On 21 Aug 2019, at 12.37, Wouter Wijngaards via Unbound-users > <[email protected]> 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
