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.
