Bind is not using the first master for freshness checks

[Klaus Darilion]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20241120/d011956e/attachment.htm>