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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
