<div dir="auto">I will say edge DNS servers reduce client config complexity, even if you have DHCP, and increase resiliency of the initial resolver. <div dir="auto"><br></div><div dir="auto">Where it's true with DHCP you can change the DHCP server options it doesn't help if someone just got a 4 day lease and then the DNS server dies.</div><div dir="auto"><br></div><div dir="auto">Additionally the abstraction layer makes patching and decom of DNS servers much easier. No config to chane just kill the box. Perhaps this is less of a concern I'd you are running a smaller environment but when you are running 400 to 500 servers in a variety of roles globally it becomes a valuable resource. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 10, 2022, 5:49 PM Grant Taylor via bind-users <<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5/8/22 5:58 AM, Tony Finch wrote:<br>
> Regarding anycast, it isn't necessary for internal authoritative <br>
> servers unless your organization is really huge (and probably not <br>
> even then): it is simpler to just use the DNS's standard reliabilty <br>
> features. All you need to do is have more than one authoritative <br>
> server for each zone.<br>
<br>
I don't know if it's a requirement for the OP or not, but Windows used <br>
to reach out to the MName server to perform dynamic updates.  So there <br>
might be some merit to the name of the MName server to be a pseudo name <br>
that resolves to an anycasted address, thus clients try to perform the <br>
dynamic update to the closest instance of the anycast / (pseudo) MName <br>
server.<br>
<br>
Aside:  Years ago, BIND secondaries would happily forward such dynamic <br>
updates the real primary MName server.<br>
<br>
Further aside:  The last time I looked, MS-DNS ADI zones would forge the <br>
local server's name as the MName to cause this type of client redirection.<br>
<br>
> On the other hand, anycast is a good way to improve the availability <br>
> and maintainability of your resolvers, because your users' devices <br>
> talk directly to them, and if they don't work there might as well <br>
> not be an Internet connection.<br>
<br>
I agree that anycasted service points make administration somewhat <br>
simpler.  However I do question the /need/ for such flexibility when <br>
things like DHCP are likely used for client configuration and can <br>
therefor manage most things automatically.<br>
<br>
<br>
<br>
-- <br>
Grant. . . .<br>
unix || die<br>
<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>