Migrating to dnssec-policy - existing "stack" of future keys ?

[Matthijs Mekking]

Hi,

On 16-11-2022 18:53, vom513 wrote:
> Hello,
> 
> I’m wanting to go ahead and look at migrating to dnssec-policy for my
> zones.  I currently use “auto-dnssec maintain” and “inline-signing
> yes”.  I also have a “stack” of ZSKs I made that all nicely overlap
> with their various date settings.  I think I made these out to
> sometime in 2024.

It is unclear to me what you mean with a "stack". But this kind of
planning is no longer needed with dnssec-policy.

> In addition to all the info here:
> 
> https://kb.isc.org/docs/dnssec-key-and-signing-policy
> 
> Do I need to / should I do something to this stack of keys ?  I was
> thinking maybe take the most “current” key, and remove his expiration
> etc.  Then (after a backup of course), delete the other future keys
> ?

You should be able to have pre-generated keys though, and as long as 
they have notbeen used before (this is maintained in the state file), 
one is randomly picked to be the successor key instead of that a new one 
is generated.

f those keys have timing metadata set, the dnssec-policy will use that 
once to initialize the current state. As long as they current keys match 
the policy, it should be alright. Timing metadata that are in the past 
are used to determine the key states. Timing metadata that are in the 
future are ignored.

If there is a difference, the dnssec-policy will perform actions to get 
to the right state (things like publish and/or withdraw DNSKEY records 
from the zone, start/stop signing with certain keys).

> In other words, I can’t imagine I’d want to mix the “old way” of
> managing these / rollovers with the new.

I agree to that.

> Hopefully this makes sense.  Thanks for any guidance or insight.
I am not entirely clear on your setup, but I hope my comments make sense 
and help you forward.

Best regards,

Matthijs