dnssec-policy makes BIND touch all key files every hour

[Matthijs Mekking]

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