KASP Key Rollover: ZSK Disappears Immediately
Nick Tait
nick at tait.net.nz
Mon Nov 13 08:55:08 UTC 2023
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>
More information about the bind-users
mailing list