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

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

เมื่อ 25/8/69 เวลา 22:32 Matthijs Mekking via bind-users เขียนว่า:
> Hi,
>
> I think this is expected, but unwanted. I should probably suppress 
> this message when offline-ksk is enabled.
>
> Best regards,
>
> Matthijs
>
>
> On 8/25/26 07:32, ThongEk via bind-users wrote:
>> Hello,
>>
>> I'm running into an issue where named floods the log with the 
>> following message:
>>
>> 24-Aug-2026 17:18:27.007 general: warning: dns_zone_findkeys: error 
>> reading Kmamao.in.th.+014+16101.private: file not found
>> 24-Aug-2026 17:18:27.015 general: warning: dns_zone_findkeys: error 
>> reading Kmamao.in.th.+014+16101.private: file not found
>> 24-Aug-2026 17:18:27.023 general: warning: dns_zone_findkeys: error 
>> reading Kmamao.in.th.+014+16101.private: file not found
>> 24-Aug-2026 17:18:27.031 general: warning: dns_zone_findkeys: error 
>> reading Kmamao.in.th.+014+16101.private: file not found
>> [... repeats every ~4-8ms ...]
>>
>> Since I'm using offline-ksk, I wouldn't expect named to be looking
>> for the KSK private key at all during routine maintenance. Here is
>> a shortened version of the relevant dnssec-policy:
>>
>> dnssec-policy "th-ecdsa384" {
>>      ...
>>      offline-ksk yes;
>>      ...
>> };
>>
>> KSK: algorithm ECDSAP384SHA384, key id 16101
>>
>> Is there something wrong with my configuration, or is this expected
>> behavior with offline-ksk?
>>
>> Additional details:
>> - This happens at specific times each day (appears correlated with
>>    the signatures-refresh boundary). Once triggered, it keeps
>>    logging continuously for roughly one hour before stopping.
>> - During this period the SOA serial is incremented on every retry
>>    (the RRSIG SOA is being resigned repeatedly), so the serial jumps
>>    by several thousand within a single episode.
>> - named also sends NOTIFY to the secondary servers on every one of
>>    these resign cycles, so this isn't just a logging issue - it's
>>    generating repeated zone journal writes and outbound NOTIFY
>>    traffic as well.
>> - The zone itself continues to resolve and validate correctly
>>    throughout - I have not observed any bogus/SERVFAIL over several
>>    months of this happening.
>>
>> versions: 9.20.24 (or possibly earlier) through 9.20.26
>>
>> Any pointers on whether this is a known issue, or something I
>> should be doing differently with the offline-ksk workflow, would be
>> appreciated.
>>
>> -- 
>> ThongEk
>>
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.