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,
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
