DNSSEC policy offline-ksk issue "dns_zone_findkeys private: file not found"

[Matthijs Mekking]

Hi,

The MR only fixes the log spam, the other issue I am not sure if it is 
an issue. If you have a configuration that requires every hour resigning 
for example.

Please open an issue, using the Bug template and fill in all the 
requested details.

https://gitlab.isc.org/isc-projects/bind9/-/work_items/new?type=Issue&initialCreationContext=list-route

Best regards,

Matthijs

On 8/29/26 06:08, ThongEk via bind-users wrote:
> Hi Matthijs,
> 
> Thanks for following up and opening #6370 and MR !12665 (https:// 
> gitlab.isc.org/isc-projects/bind9/-/work_items/6370 , https:// 
> gitlab.isc.org/isc-projects/bind9/-/merge_requests/12665)
> 
> Looking at the diff (908f85db), it appears the fix only adds a condition 
> to suppress the "error reading" log line when offline-ksk is enabled - 
> it doesn't seem to touch the resign scheduling or NOTIFY logic itself.
> 
> Could you confirm whether MR !12665 is intended to fix only the log 
> spam, or whether the underlying resign loop (the ~1 hour episode with 
> repeated SOA serial increments and NOTIFY sends I described earlier) is 
> also being addressed, either in this MR or separately?
> 
> My concern is that once the warning log is suppressed, the resign loop - 
> if it's still happening - would run silently in the background with no 
> visible indication in the logs, which would make it much harder to 
> notice or diagnose going forward.
> 
> Best regards,
> 
> -- 
> ThongEk
> 
> เมื่อ 26/8/69 เวลา 15:18 Matthijs Mekking via bind-users เขียนว่า:
>> Hi,
>>
>> It is on my radar. You can expect a fix for it in a nearby version.
>>
>> You can track the issue here:
>>
>> https://gitlab.isc.org/isc-projects/bind9/-/work_items/6370
>>
>> Best regards,
>>
>>
>> On 8/26/26 07:33, ThongEk via bind-users wrote:
>>> Hi Matthijs,
>>>
>>> Is there a known workaround on the operator side to prevent the 
>>> resign loop/NOTIFY storms from firing at all when offline-ksk is set?
>>> Otherwise I'd expect this to become a real bandwidth/load concern for 
>>> anyone running several offline-ksk zones on the same server.
>>>
>>> Also, is this something I should be filing somewhere more formal (I'm 
>>> not very familiar with the issue tracker workflow), or is this 
>>> already on your radar as something to fix along with the log message?
>>>
>>>
>>> Best regards,
>>