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