On 3/11/23 10:43 AM, Fred Morris wrote:
I've found myself in situations in the past where NOTIFY has been
fetishized as "real time"
"real time" can be a VERY loaded phrase.
Some sometimes it's measured in fractions of a second. Other times it's
measured in minutes.
I've always simply
I've found myself in situations in the past where NOTIFY has been
fetishized as "real time", and nobody ever ever asked which upstream
server was being queried as a result. So this has been an eye-opening
thread, and if I ever find myself in that situation again it'll give me
something else to
On 3/11/23 10:37 AM, Paul Stead wrote:
Sorry I should have made it clearer that the notifier should only be
shuffled to the top of the list if it is a defined primary for said zone.
Okay. The try the notifier first /if/ it's a configured primary makes
more sense to me. I guess I've not had
Sorry I should have made it clearer that the notifier should only be
shuffled to the top of the list if it is a defined primary for said zone.
I.e An IP on the notify-from list, but not a configured primary wouldn't be
in the list of primaries for that zone so would not be shuffled to the top
of
Hi Paul,
Thank you for explaining.
On 3/10/23 12:21 AM, Paul Stead wrote:
Imagine that 1.1.1.1 has lost network connectivity recently. A notify
comes from 2.2.2.2 - if I understand correctly Bind will try 1.1.1.1
first, time out and then try 2.2.2.2 - even though we know given the
situation
On 09/03/2023 21:25, Klaus Darilion via bind-users wrote:
[snip]
PS: Latest PowerDNS tries the NOTIFY source first. MAybe someone
knows how Knot and NSD behave?
Knot DNS only tries to refresh from primaries that sent the NOTIFY. It
doesn't even try the other configured primaries. However, if
On Thu, 9 Mar 2023, 23:53 Grant Taylor via bind-users, <
bind-users@lists.isc.org> wrote:
> On 3/9/23 2:25 PM, Paul Stead wrote:
> > Chiming in to say +1 to Kalus' logic and sight of benefit here.
>
> Please forgive my ignorance in asking:
>
> Why doesn't the order of the configured primaries
On 3/9/23 2:25 PM, Paul Stead wrote:
Chiming in to say +1 to Kalus' logic and sight of benefit here.
Please forgive my ignorance in asking:
Why doesn't the order of the configured primaries suffice?
N.B. I'm assuming that this is the the order of the primaries for a zone
in the named.conf
On Thu, 9 Mar 2023, 20:27 Klaus Darilion via bind-users, <
bind-users@lists.isc.org> wrote:
> > -Ursprüngliche Nachricht-
> > Von: bind-users Im Auftrag von Mark
> > Andrews
> > Gesendet: Donnerstag, 9. März 2023 21:04
> >
> > Named just uses the notify to trigger an early refresh
> -Ursprüngliche Nachricht-
> Von: bind-users Im Auftrag von Mark
> Andrews
> Gesendet: Donnerstag, 9. März 2023 21:04
> An: Jan-Piet Mens
> Cc: bind-users@lists.isc.org
> Betreff: Re: Correlation between NOTIFY-Source and AXFR-Source
>
> Named just uses the
Named just uses the notify to trigger an early refresh process. It then just
asks the primaries in configured order. There is no real point in trying the
notifier first.
--
Mark Andrews
> On 10 Mar 2023, at 06:00, Jan-Piet Mens wrote:
>
>
>>
>> I always was quite sure that Bind will
I always was quite sure that Bind will request XFR from the Primary that sent
the NOTIFY.
my understanding has always been that the primaries are tried in configured
order.
Looking forward to hear which is actually correct. :)
-JP
--
Visit
Hello!
I always was quite sure that Bind will request XFR from the Primary that sent
the NOTIFY.
config:
masters {
X.X.X.4;
X.X.X.20;
};
Bind Version 9.11.5.P4+dfsg-5.1+deb10u8
But I just saw this in the logs that the first NOTIFY is received from .20, but
AXFR is
13 matches
Mail list logo