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
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
the default one
with a greater amount of patience.
From: bind-users on behalf of Nick Tait via
bind-users
Sent: Friday, September 29, 2023 5:37 PM
To: bind-users@lists.isc.org
Subject: Re: KASP Key Rollover: ZSK Disappears Immediately
Sorry I just realised that all
Sorry I just realised that all that waffle about DS records is only
relevant for KSKs (and CSKs), not ZSKs. So please disregard that. :-P
But I think the "rumoured" vs. "omnipresent" thing is still relevant and
is the most likely explanation for why the old ZSK doesn't stick around.
I can
On 29/09/23 12:05, Eddie Rowe wrote:
When I perform a ZSK key rollover the existing ZSK disappears
*immediately* so not sure what I am missing when using the KASP to
manage key rollover. The state for the keys looks good and for this
test I have TTL set to 1 hour.. But why does dig not show
When I perform a ZSK key rollover the existing ZSK disappears immediately so
not sure what I am missing when using the KASP to manage key rollover. The
state for the keys looks good and for this test I have TTL set to 1 hour.. But
why does dig not show me both DNSKEY records for the ZSK after
6 matches
Mail list logo
