Hi Mark!
I read https://kb.isc.org/docs/aa-01467 especially:
"The servers are queried in turn - named moves on to the next server in the
list if either:
- It is unable to get a response from the server it is currently querying
(this might be no response or an error response).
- The primary being queried returns the same (or smaller) SOA than the
secondary is currently serving.
"
I guess, the "new refresh cycle", triggered by the NOTIFY during the concurrent
refresh/XFR, does not remember the serial of the NOTIFY.
In my case, the NOTIFY that triggered the "new refresh" contained the same
serial as the NOTIFY that triggered the previous refresh. (So, actually the
"new refresh" would not be needed.) As the new refresh does not find a serial
on the primary higher than the current served serial, the "new refresh check"
tries all configured masters, and this is causing problems as the last master
is not responding, correct?
Wouldn't it make sense to trigger a "new refresh" only if the received NOTIFY
has a higher serial than the one handled in the current refresh?
Regards
Klaus
> -----Original Message-----
> From: Mark Andrews <ma...@isc.org>
> Sent: Thursday, November 21, 2024 12:26 AM
> To: Klaus Darilion <klaus.daril...@nic.at>
> Cc: bind-users@lists.isc.org
> Subject: Re: Bind is not using the first master for freshness checks
>
> 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-
> us...@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
