KASP Key Rollover: ZSK Disappears Immediately

Matthijs Mekking matthijs at isc.org
Mon Nov 13 09:15:07 UTC 2023


Hi Nick,

The timings are based on what is configured in the dnssec-policy: It is 
too costly to observe the zone every time to see if there is still a 
signature of the predecessor key. So yes: it takes the maximum possible 
time to determine when all signatures have been replaced.

This time is Iret (based on RFC 7583) and the main portion of that is 
Dsgn, the delay needed to ensure that all existing RRsets have been 
re-signed with the new key. The maximum sign delay is:

     Dsgn = (signatures-validity - signatures-refresh)

In the default policy this is indeed 9 days.

I still suspect that the original issue from Eddie was because the KSK 
had its DS state in hidden.

Best regards,

Matthijs

On 11/13/23 09:55, Nick Tait via bind-users wrote:
> On 03/10/2023 09:59, Eddie Rowe wrote:
>> I appreciate the feedback.  I did make sure the ZSK is omnipresent and the
>> issue still happens so it might be that my attempt to take the default 
>> policy
>> and bring it down to 1 day to hurry along testing.  I will see if I 
>> can find
>> any test policies in the list archives and failing that use the 
>> default one
>> with a greater amount of patience.
> Hi Eddie.
> 
> Not sure if you're still interested in this topic, but a couple of weeks 
> ago I did a manual ZSK roll-over, to see if I observed results similar 
> to what you described in your original email...
> 
> Before starting the rollover /everything/ was showing omnipresent.
> 
> After initiating the rollover things mostly happened in the expected 
> timeframes, but there was one thing that surprised me: The old ZSK 
> removal date was set 9-and-a-bit days(!) after the roll-over was 
> initiated, and the old ZSK and new ZSK state files showed "ZRRSIGState: 
> unretentive" and "ZRRSIGState: rumoured" (respectively) right up until 
> the old ZSK removal date, before eventually transitioning to the 
> expected end states of "ZRRSIGState: hidden" and "ZRRSIGState: 
> omnipresent" (respectively). This was in spite of the fact that all 
> RRSIG records were replaced with the new ZSK more than a week prior. I 
> can only assume that the 9 days somehow relates to how long BIND wanted 
> to allow itself to generate RRSIGs for all the records in a really, 
> really large zone file?
> 
> Anyway, I remembered seeing "ZRRSIGState: rumoured" in your ZSK state 
> file before you initiated your ZSK roll-over, and so I suspect that all 
> your issues stem from the fact that not everything was omnipresent 
> before you initiated the roll-over?
> 
> Nick.
> 


More information about the bind-users mailing list