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
--
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
