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

Matthijs Mekking matthijs at isc.org
Tue Aug 25 15:32:51 UTC 2026


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
> 



More information about the bind-users mailing list