Determining Which Authoritative Sever to Use

[Bob McDonald]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220511/9ca7e0ab/attachment.htm>