Re: KASP Key Rollover: ZSK Disappears Immediately

2023-11-13 Thread Nick Tait via bind-users

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


Re: KASP Key Rollover: ZSK Disappears Immediately

2023-11-13 Thread Matthijs Mekking

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 is Iret (based on RFC 7583) and the main portion of that is 
Dsgn, the delay needed to ensure that all existing RRsets have been 
re-signed with the new key. The maximum sign delay is:


Dsgn = (signatures-validity - signatures-refresh)

In the default policy this is indeed 9 days.

I still suspect that the original issue from Eddie was because the KSK 
had its DS state in hidden.


Best regards,

Matthijs

On 11/13/23 09:55, Nick Tait via bind-users wrote:

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