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.
