<div dir="ltr"><div dir="ltr" class="gmail_attr">On Thu, 9 Mar 2023, 23:53 Grant Taylor via bind-users, <<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/9/23 2:25 PM, Paul Stead wrote:<br>
> Chiming in to say +1 to Kalus' logic and sight of benefit here.<br>
<br>
Please forgive my ignorance in asking:<br>
<br>
Why doesn't the order of the configured primaries suffice?<br>
<br>
N.B. I'm assuming that this is the the order of the primaries for a zone <br>
in the named.conf file and not actually zone contents.<br>
<br>
What am I failing to understand?<br></blockquote><div><br></div><div>For much the reasons Klaus cited, really.</div><div><br></div><div>Given the example:</div><div><br></div><div>masters {</div><div>  1.1.1.1</div><div>  2.2.2.2<br></div><div>};</div><div><br></div><div>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 that 2.2.2.2 has the latest copy of the zone we want.</div><div><br></div><div>For what it's worth, NSD also seems to follow the logic of using the notifier as the next master/primary to target - xfrd.c - xfrd_handle_passed_packet</div><div><br></div><div>Paul<br></div></div>
</div>