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.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
