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

ThongEk viverridae at nusara.co.uk
Sat Aug 29 04:08:45 UTC 2026


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,
>


More information about the bind-users mailing list