KASP Key Rollover: ZSK Disappears Immediately

[Nick Tait]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20231113/37b45344/attachment.htm>