Bind is not using the first master for freshness checks

[Mark Andrews]

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 at 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 at 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: marka at isc.org