Bjørn,
Perhaps you hit another quirk in the migration. I'll try to explain what
is happening, or what is supposed to happen.
When migrating to dnssec-policy, there are no state files. BIND tries to
deduce the state from the timing metadata and the durations from
dnssec-policy.
For the DS, BIND examines the "SyncPublish" time and checks it against
the current time (when migrating). If enough time has passed since
"SyncPublish" the "DSState" will be set to "omnipresent", otherwise it
will be "rumoured":
if (syncpub <= now && ret == ISC_R_SUCCESS) {
dns_ttl_t ds_ttl = dns_kasp_dsttl(kasp);
ds_ttl += dns_kasp_parentpropagationdelay(kasp);
if ((syncpub + ds_ttl) <= now) {
ds_state = OMNIPRESENT;
} else {
ds_state = RUMOURED;
}
goal_state = OMNIPRESENT;
}
I am not sure what the "SyncPublish" value is in your key file, but
maybe this is a hint to why the "DSState" is set to "rumoured".
What can you do to get it to "omnipresent"? Tell BIND that the DS is in
the parent (only do so if it is true of course). You can run
rndc dnssec -checkds published your.zone
And it should update the keyfile. You should then see a "DsPublish" line
in the state file and wait for DS TTL and parent propagation delay time
to see the state switch to "omnipresent".
If there are multiple keys eligible you need to specify the key id with
"-key id".
Hope this helps, and if not, please let me know.
Best regards,
Matthijs
On 26-04-2022 10:50, Bjørn Mork wrote:
Matthijs Mekking <matth...@isc.org> writes:
To be precise, BIND updates the key files each keymgr run. But If the
keymgr waits for an event (rather than a duration), it will retry
every refresh key interval, which defaults to an hour.
You can check the logs for "next key event" to see when the keymgr is
scheduled next.
But yes, each time the keymgr runs for a zone, the key files are
written out for that zone. You are right that this is unnecessary. I
have created a GitLab issue for this to fix it.
https://gitlab.isc.org/isc-projects/bind9/-/issues/3302
Thanks for explaining. This makes sense.
I guess that the event the keymgr is waiting for must be DSState update
for the active KSK? Which is another thing I haven't been able to
figure out.
Since I have only migrated existing keys, all states are either "hidden"
(for deleted keys) or "omnipresent". Except for DSState which is
"rumoured". And I don't understand why, or what I can do to change that.
For example:
bjorn@louie:~$ grep . /etc/bind/dnssec/dyn.mork.no/Kdyn.mork.no.+013+63342.state
; This is the state of key 63342, for dyn.mork.no.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: no
Generated: 20181012184125 (Fri Oct 12 19:41:25 2018)
Published: 20181012184500 (Fri Oct 12 19:45:00 2018)
Active: 20181012184500 (Fri Oct 12 19:45:00 2018)
PublishCDS: 20181013195000 (Sat Oct 13 20:50:00 2018)
DNSKEYChange: 20220405085059 (Tue Apr 5 09:50:59 2022)
KRRSIGChange: 20220405085059 (Tue Apr 5 09:50:59 2022)
DSChange: 20220405085059 (Tue Apr 5 09:50:59 2022)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent
The DS records for all these zones have been active for years. I see
that BIND created new and mostly (except for TTL) matching CDS records
when I migrated to dnssec-policy. Is the TTL mismatch the problem? Or
is BIND waiting for something else to happen to this (C)DS record?
I guess I could try to sync the TTL for the internal delegations. But
this is rarely an option for most of the zones with externally managed
parents.
I found https://gitlab.isc.org/isc-projects/bind9/-/issues/2544
describing this problem, but the solutions is still unclear to me.
Maybe it's just a transitional problem when migrating to dnssec-policy?
Bjørn
--
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
