Struggling with dnssec-policy timers

[Matthijs Mekking]

Hi,

On 27-11-2022 23:32, vom513 wrote:
> Hello all,
> 
> I’m still having a really hard time understanding and getting my
> timings right.  At least I think I am (from the way I’m reading the
> status/logs/state files).
> 
> I let my current CSK get completely “omnipresent” for all it’s timers
> (I’m not even sure if this is really necessary…)  I did a rollover,
> and I’m very confused by the various timers I’m seeing.
> 
> FYI - I added:
> 
> publish-safety 1d; retire-safety 1d;
> 
> To the policy “default”.  Other than that and NSEC3, everything is
> using values from the “default” policy.  With this, it seems that my
> successor key will go active but CDS won’t be published until the
> same exact time.  This seems to defeat the purpose of doing an
> overlapping rollover.  I would think I would want CDS published
> before the new key goes active.  Is the old key going to keep being
> used for signing as well ?  I don’t think so because it’s retirement
> is also at this exact moment.
The CDS cannot be published before the new key is active. BIND 9
performs a Double DNSKEY rollover, so only after the new key is active,
the DS may be published in the parent (and publishing CDS is an
indication that the DS may be published).


> So simultaneously, it seems that I have:
> 
> - New key start to be used for signing - CDS is published - Old key
> is retired
> 
> If I’m reading this right - did my timers screw this up ?  I would
> have hoped/assumed that the “default” policy would have timers
> arranged as such as there there *should* not be any gaps in coverage
> (assuming everything else goes swimmingly…)  I’ll be honest - I’m
> kind of feeling like an idiot because of how difficult this seems.

I assume you used "rndc dnssec -rollover" to initiate a rollover 
(because the default policy has key lifetime unlimited).

I don't know what times you expect, but the timings look fine to me. The 
current key 35731 will be retired today (20221128231500 (Mon Nov 28 
18:15:00 2022), and at that time the successor key 3697 will become active.

Because at this point there are two DNSKEY's omnipresent (i.e. known to 
the world), it is safe to swap the DS.

So unless I am misunderstanding, I think all is fine?

Best regards,

Matthijs



> Can someone please set me straight ?  I can “nuke” this zone’s keys
> and state and start over (which I’ve done several times already).
> It’s just getting a bit tiresome because of course when I do this all
> the various timers start over.
> 
> Here are my state files, 2 keys.  Current and a successor.  Thanks in
> advance.
> 
> — ; This is the state of key 3697, for acuity.tech. Algorithm: 13 
> Length: 256 Lifetime: 0 Predecessor: 35731 KSK: yes ZSK: yes 
> Generated: 20221127221000 (Sun Nov 27 17:10:00 2022) Published:
> 20221127221000 (Sun Nov 27 17:10:00 2022) Active: 20221128231500 (Mon
> Nov 28 18:15:00 2022) PublishCDS: 20221128231500 (Mon Nov 28 18:15:00
> 2022) DNSKEYChange: 20221127221000 (Sun Nov 27 17:10:00 2022) 
> ZRRSIGChange: 20221127221000 (Sun Nov 27 17:10:00 2022) KRRSIGChange:
> 20221127221000 (Sun Nov 27 17:10:00 2022) DSChange: 20221127221000
> (Sun Nov 27 17:10:00 2022) DNSKEYState: rumoured ZRRSIGState: hidden 
> KRRSIGState: rumoured DSState: hidden GoalState: omnipresent
> 
> ; This is the state of key 35731, for acuity.tech. Algorithm: 13 
> Length: 256 Lifetime: 546573 Successor: 3697 KSK: yes ZSK: yes 
> Generated: 20221122152527 (Tue Nov 22 10:25:27 2022) Published:
> 20221122152527 (Tue Nov 22 10:25:27 2022) Active: 20221122152527 (Tue
> Nov 22 10:25:27 2022) Retired: 20221128231500 (Mon Nov 28 18:15:00
> 2022) Removed: 20221209232000 (Fri Dec  9 18:20:00 2022) DSPublish:
> 20221123043555 (Tue Nov 22 23:35:55 2022) PublishCDS: 20221124153027
> (Thu Nov 24 10:30:27 2022) DNSKEYChange: 20221123163027 (Wed Nov 23
> 11:30:27 2022) ZRRSIGChange: 20221124153027 (Thu Nov 24 10:30:27
> 2022) KRRSIGChange: 20221123163027 (Wed Nov 23 11:30:27 2022) 
> DSChange: 20221125053555 (Fri Nov 25 00:35:55 2022) DNSKEYState:
> omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent 
> DSState: omnipresent GoalState: hidden
>