I was never able to uncover the underlying problem with that update.
The only clue I had was the service remained in "activating" state,
rather than "running". named was listening as expected, was transfering
zone data, was caching and serving the correct data, but didn't seem to
recognize it had the same data when it next retrieved the SOA record.
I eventually restored the secondary host from backup, and performed the
upgrade from 9.18.10 --> 9.18.11 again. It behaves exactly as expected;
retrieving the SOA record, recognizing it already has that serial
number, and waiting patiently for the refresh interval to expire before
checking again.
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
On 1/27/2023 1:53 AM, Ondřej Surý wrote:
FTR I am not aware of any change between 9.18.10 and 9.18.11 that might cause
the described behaviour.
That said - in addition to what Greg said, I would suggest increasing the log
level to small debug levels if you can and perhaps something will stand out
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
