If a notify comes in while refresh / transfer is in progress that is noted and
a new
refresh cycle is started when the current refresh cycle / transfer completes.
Note named is NOT logging every refresh attempt. It is logging refresh attempt
FAILURES
so you know what to fix.
Mark
> On 21 Nov 2024, at 00:27, Klaus Darilion via bind-users
> <bind-users@lists.isc.org> wrote:
>
> Hello!
> Version: 9.18.30-1+ubuntu24.04.1+deb.sury.org+1
> masters {
> AA.BB.4.13 key rcodezero;
> 2xxx:xxx:9c:2031::4 key rcodezero;
> AA.BB.6.13 key rcodezero;
> 2xxx:xxx:40:2031::4 key rcodezero;
> };
> For some reason, the last 2 IP addresses are currently not responding to
> requests. Nevertheless our Bind secondary tries to contact them. That
> confuses me, as I read quite some time that a NOTIFY (regardless of the
> src-IP) just triggers a freshness check and during the freshness check, Bind
> uses the configured masters in the order of the configuration.
> Here is a log excerpt:
> 10:47:48 zone redacted/IN: transferred serial 1106744096: TSIG 'rcodezero'
> 10:47:48 transfer of 'redacted/IN' from AA.BB.4.13#53: Transfer status:
> success
> 10:47:48 transfer of 'redacted/IN' from AA.BB.4.13#53: Transfer completed: 1
> messages, 60 records, 9138 bytes, 0.026 secs (351461 bytes/sec) (serial
> 1106744096)
> 10:47:48 zone redacted/IN: sending notifies (serial 1106744096)
> 10:47:53 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744098:
> refresh in progress, refresh check queued
> 10:47:53 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#32880: serial
> 1106744098: refresh in progress, refresh check queued
> 10:47:53 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744098: refresh in progress, refresh check queued
> 10:47:53 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744098: refresh in progress, refresh check queued
> 10:47:58 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744099:
> refresh in progress, refresh check queued
> 10:47:58 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#36818: serial
> 1106744099: refresh in progress, refresh check queued
> 10:47:58 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744099: refresh in progress, refresh check queued
> 10:47:58 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744099: refresh in progress, refresh check queued
> 10:48:03 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744100:
> refresh in progress, refresh check queued
> 10:48:03 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#56591: serial
> 1106744100: refresh in progress, refresh check queued
> 10:48:03 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744101: refresh in progress, refresh check queued
> 10:48:03 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744101: refresh in progress, refresh check queued
> 10:48:08 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744101:
> refresh in progress, refresh check queued
> 10:48:08 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#37105: serial
> 1106744101: refresh in progress, refresh check queued
> 10:48:14 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744102:
> refresh in progress, refresh check queued
> 10:48:14 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#36695: serial
> 1106744102: refresh in progress, refresh check queued
> 10:48:14 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744102: refresh in progress, refresh check queued
> 10:48:14 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744102: refresh in progress, refresh check queued
> 10:48:18 zone redacted/IN: refresh: retry limit for primary AA.BB.6.13#53
> exceeded (source 83.136.34.6#0)
> So, the last inbound XFR was successful performed using the first configured
> master. Hence, that master should not be tagged as “down”.
> A few seconds later, the received NOTIFY is ignored with “refresh check
> queued”. That is strange as nobody triggered a refresh and SOA refresh is
> high and max-refresh-time=300.
> Anyway the “refresh in progress” takes very long, and after 30s the reason is
> obvious: retry limit for primary AA.BB.6.13#53 exceeded
> So why is Bind using a master for refresh which is not the first in the list?
> Thanks
> Klaus
> -- Klaus Darilion, Head of Operations
> nic.at GmbH, Jakob-Haringer-Straße 8/V
> 5020 Salzburg, Austria
> --
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
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
