Public facing authoritative NS all masters

Joseph S D Yao jsdy at tux.org
Sun Jul 13 19:19:55 UTC 2014


On 2014-07-13 12:11, Gary Wallis wrote:
> Hello,
>
> What are the drawbacks, if any, of running only master name servers
> for the set of authoritative NSs?
>
> For example given:
>
> [root at rc37 unxsVZ]# dig latimes.com NS +short
> dns1.tribune.com.
> dns2.tribune.com.
> dns4.tribune.com.
> dns3.tribune.com.
>
> Where all 4 dnsN servers are in fact masters (this is just a
> hypothetical, the NS above are most likely secondary servers)
...

If you think about it, it is not the servers themselves that are master 
or slave.  For each zone, it is the copy of that zone that is considered 
a master copy on that server, or a copy slaved to the copy on another 
server.  And this can be different for each zone served on those 
servers.

There should in fact be only one master copy that you change, for each 
zone, and the other name servers somehow get an identical copy of that 
master copy.

Whether all four of the visible authoritative name servers are 
configured to have "master" in their internal configurations, saying to 
use the copy of the zone found on disk, or "slave", saying to use the 
DNS standard method of slaving the server's copy to a copy of that zone 
found on another server, is in fact invisible to users and irrelevant to 
them.  What is important is that all servers declared as authoritative 
for that one zone DO serve that zone, and respond with the same 
information.  All four could be configured as having a "master" copy of 
a zone and get it by other means from a hidden master copy, or all four 
could be configured as having "slave" copies slaved to, again, a hidden 
master copy; or some combination (e.g., 4's copy is slaved to 3's copy 
which is slaved to 2's copy, and both 1 and 2 are declared as having 
master copies and get them via SCP from a hidden master, just to get 
complicated).

Now, what was the reason you asked this question?  Is there an 
underlying question behind that?

Joseph Yao


More information about the bind-users mailing list