<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 03/10/2023 09:59, Eddie Rowe wrote:
<blockquote type="cite"
cite="mid:27cb0021-c87c-8bf6-6d92-2ed112258f37@tait.net.nz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I appreciate the feedback. I did make sure the ZSK is omnipresent
and the<br>
issue still happens so it might be that my attempt to take the
default policy<br>
and bring it down to 1 day to hurry along testing. I will see if
I can find<br>
any test policies in the list archives and failing that use the
default one<br>
with a greater amount of patience.<br>
</blockquote>
Hi Eddie.<br>
<p>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...<br>
</p>
<p>Before starting the rollover <i>everything</i> was showing
omnipresent.</p>
<p>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?<br>
</p>
<p>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?<br>
</p>
Nick.
</body>
</html>