dnssec-policy makes BIND touch all key files every hour

[Matthijs Mekking]

Hi,

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

Best regards,

Matthijs


On 25-04-2022 18:49, Laurent Frigault wrote:
> On Sun, Apr 24, 2022 at 11:58:44AM +0200, Bjørn Mork wrote:
> Hello,
>   
>> I recently moved a few zones from "auto-dnssec maintain" to
>> "dnssec-policy ..." to prepare for simpler/automatic key rotation in the
>> future.
>>
>> For the time being I have configured my policy with separate KSK and ZSK
>> and unlimited key life times to replicate the old setup as closely as
>> possible.  I also had a few old and outdated keys lying around, and
>> would like to keep those, so my policy has "purge-keys 0".  All other
>> policy settings are default.
>>
>> The setup is mostly working as expected - which is great.  But there is
>> one issue which has suprised me, and which is slightly annoying since it
>> tends to set off a few security warnings:  All the key related files are
>> now touched by BIND once an hour, whether they are modified or not.
>> Which they obviously nevery should be, given my current policy.
> 
> I discover the same issue with bind 9.16.27 and FreeBSD 13.0
>   
>> This is particularily surprising wrt the deleted keys. But it's equally
>> unnecessary with the current keys. And touching those is actually more
>> annoying since it's an unexpected file system operation with real
>> security implications.  Or at least it feels that way...
> 
> My test server run only a few zones and only one with dnssec-policy but
> I have a production serveur with more than 70 000 zones. This issue
> would generate avec very high IO load on such server.
> 
>> Is this expected or am I doing something wrong?  And if this is
>> expected, then why?
> 
> Good question.
>