It's always an architectural choice to use anycast with your authoritative zones. I'm speaking from purely a private network (inside) viewpoint. I typically only use anycast for recursive DNS servers on my private (internal) network.
That said, here are some thoughts. (This is my understanding only) A default primary/secondary DNS zone setup as per the relevant RFCs includes one primary DNS server name in the MNAME field of the SOA record for that DNS zone. Following a non-Windows update procedure, a device (client of DHCP server - specified by DHCP option 81) sends a DNS query for the zone SOA record. It then sends a dynamic update to the specified MNAME server found in the reply to the SOA record query. Windows can be a bit different. If, for example, the zone to be updated is an Active Directory integrated DNS zone then this applies; a DHCP client sends a rDNS request for SOA to it's local DNS server. Because this is an Active Directory integrated DNS zone, each DC running DNS places it's own name in the MNAME field. Now the update request goes to the local DC running DNS. This spreads out the update request workload. There is a more convoluted process involving stepping through the NS records looking for a valid update server if the update should fail. This also does not take into account any security involved with said updates. Going back to "normal" DNS setups. If the MNAME in the SOAis replaced with another name, this is an example of a truly hidden master. Updates sent in this case require allow-update-fowarding to be set to any. This may on the surface seem like it will do the trick but unsecured (those without tsig or gss-tsig) update requests may be hard to troubleshoot. Forwarding the update replaces the update origin IP with that of the secondary server that forwards the request. It would seem that using an anycast cloud name (An anycast cloud of the NS device IPs) for the MNAME might provide the same level of distribution as per Windows. However, again, you run into the issues of forwarded updates. More testing would need to be done to see if secured updates actually identify the correct requester in the log files. In summary, there are SEVERAL methods to explore here and tons of options within DNS and DHCP that might have some bearing on this also. Then there's the holy war about the security of gss-tsig signed updates. Anyway, I've been looking at this for the last decade. I'm sure I'll discover more along the way. Bob
-- 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
