On 16/05/22 21:34, Matthijs Mekking wrote:
Hi Nik,
On 16-05-2022 07:49, Nick Tait via bind-users wrote:
Hi there.
Ever since I updated my BIND configuration to use the new
dnssec-policy feature (a year or so ago) my KSK/CSK rollovers have
been a complete shambles. My problems stem from the inference (based
documentation and examples) that running "rndc dnssec -checkds
published" tells BIND that the DS record is now published in the
parent zone? Based on that predicate, it would be my expectation that
after running this command above, the DSState should immediately
transition from "rumoured" to "omnipresent".
This assumption is incorrect. Once the DS is in the parent, validators
do not immediately know about the new DS record. That why it is rumoured.
Being omnipresent means that every resolver will use the new DS record
for validation purposes, whether they have it in the cache, or
retrieve it from the parent zone. More importantly this means that any
previous versions of the DS RRset are not known anywhere.
In past rollovers, the DSState hasn't transitioned from "rumoured".
And then I've thought "oh it must be a bug" and so I've set about
trying to force the DSState to change to "omnipresent". And suffice
to say that the shambles followed on from there...
So anyway, since I'd recently upgraded to BIND 9.18.1 (as part of
Ubuntu 22.04 upgrade), and thinking maybe these 'bugs' might now be
fixed, I thought I'd have another look at it, but this time I'll pay
more attention to what is going on, and try to be less impatient...
Before I did anything the key state file looked like this:
Algorithm: 15
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20211024221429 (Mon Oct 25 11:14:29 2021)
Published: 20211024221429 (Mon Oct 25 11:14:29 2021)
Active: 20211024221429 (Mon Oct 25 11:14:29 2021)
PublishCDS: 20211025231929 (Tue Oct 26 12:19:29 2021)
DNSKEYChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
ZRRSIGChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
KRRSIGChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
DSChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent
As you can see the DSState was "rumoured" before I started. So the
first thing I did was run "rndc dnssec -checkds published", and this
added the following line to the state file:
DSPublish: 20220515001647 (Sun May 15 12:16:47 2022)
However the DSState value remained "rumoured". So then I thought,
I'll wait a TTL or two (TTL for DS and DNSKEY are both 1 hour --
although I wouldn't expect BIND to know the DS TTL). But still
nothing changed. So then I decided I'd leave it alone until the next
day. When I checked after ~20 hours elapsed time, still nothing had
changed.
I checked again just now, and finally the DSState has changed to
"omnipresent". Here are the lines in the state file that have changed:
DSChange: 20220516021647 (Mon May 16 14:16:47 2022)
DSState: omnipresent
So my big question is this: Is it expected that the DSState won't
change until 26 hours after the "rndc dnssec -checkds published"
command is run? And if so why does it take so long?
That depends on your dnssec-policy. BIND will/should move the DSState
to omnipresent after an x amount of time, where:
x = parent-ds-ttl + parent-propagation-delay + retire-safety
By default these values are
parent-ds-ttl: 24h
parent-propagation-delay: 1h
retire-safety: 1h
So the 26 hours add up.
Now these may be very conservative values, but for the default policy
we rather wait a little longer than too short.
Best regards,
Matthijs
Thanks so much for the explanation. Makes perfect sense now. :-)
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
