<div dir="auto">I would concur that internally Anycast is best for client facing edge nodes to reduce client configuration complexity as well as reducing impact of a first resolver outage.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 8, 2022, 7:59 AM Tony Finch <<a href="mailto:fanf@isc.org">fanf@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bob McDonald <<a href="mailto:bmcdonaldjr@gmail.com" target="_blank" rel="noreferrer">bmcdonaldjr@gmail.com</a>> wrote:<br>
><br>
> My question is this; how do the recursive servers determine from<br>
> the information in the stub zone which name server to query?<br>
<br>
As well as what Bob Croswell said about SRTT (which is entirely correct),<br>
there's a subtlety with stub zones in particular.<br>
<br>
A stub zone works a bit like the root zone hints, in that the name servers<br>
that you configure are just used to find the zone's NS records. This means<br>
that stub zones don't override where queries are routed for these zones.<br>
If you want your resolver to ignore the NS records on your internal zones,<br>
you should use static-stub instead.<br>
<br>
Regarding anycast, it isn't necessary for internal authoritative servers<br>
unless your organization is really huge (and probably not even then): it<br>
is simpler to just use the DNS's standard reliabilty features. All you<br>
need to do is have more than one authoritative server for each zone.<br>
On the other hand, anycast is a good way to improve the availability and<br>
maintainability of your resolvers, because your users' devices talk<br>
directly to them, and if they don't work there might as well not be an<br>
Internet connection.<br>
<br>
-- <br>
Tony Finch  <<a href="mailto:fanf@isc.org" target="_blank" rel="noreferrer">fanf@isc.org</a>>  (he/they)  Cambridge, England<br>
Selsey Bill to Lyme Regis: East or southeast, veering south later, 2<br>
to 4. Smooth or slight, occasionally moderate for a time offshore.<br>
Fair. Good.<br>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank" rel="noreferrer">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>