Back when the DNS were created (the good ol' days) the terms "Primary" and "Secondary" were used but were abandoned due to its misleading and misunderstood names. A common misconception was that a "Secondary" DNS server had old data and some people would only query "Primary" DNS servers. "Primary" was replaced by "Master" and "Secondary" were replaced by "Slave" to limit unnecessary confusion. Lately due to political reasons the terms "Primary" and "Secondary" has once again become popular...

DNS infrastructure in its essential parts are very straight forward. We will start with the bare minimum and work our way forward from there. But let's establish a couple of fundamental security guidelines:

• Always, as a security minimum, make sure that traffic from the Internet only are able to reach your DNS servers on application port 53, both over UDP and TCP.
• Always make sure the servers have the correct time, or at least keep the DNS servers on the same time if correct time is unachievable.

We will not go into specific configuration statements for certain types of DNS software but the configuration suggested should be available, one way or the other, from all major DNS vendors.

This is a basic setup with a Master DNS, from where we edit our zone files, and two Slave DNS servers. The Master and Slave servers are all listed in the NS resource records. The DNS protocol scrambles the order of the DNS servers in every query response which makes sure the query load on each authoritative DNS server is fairly equal.

This is an infrastructure that is quite easy to maintain but has a few drawbacks. The main drawback is that the Master DNS is equally exposed to the Internet as the Slave DNS servers are, and since the Master DNS is the source of origin for our domains we might want to increase security for it a bit.

By excluding the Masters name from the NS resource records we create a "Hidden Master" configuration. By placing the Master DNS behind a firewall (illustrated in the picture below by the red dotted line) and set up rules that only allows DNS traffic to the Master from each of it Slaves we increase the security and lower the exposure to the Master.

Note that the Master DNS is still visible in the SOA resource record by the Master Name.

As far as Multi-master concepts go the Microsoft AD is by far the most implemented multi master DNS concept out there. Microsoft DNS servers  are rarely seen on the Internet though. Microsoft defaults a DNS server on each Domain Controller (you can opt out if you wish), using AD synchronisation instead of zone transfers to keep every master DNS in sync. As you probably know, edits to any Domain Controller is immediately replicated to all other DC's. Take a note that in a Microsoft DNS implementation there are no real Slave servers.

In most implementations the multiple masters also serve as recursive resolvers.

The easiest approach with a multi master concept is to have two identical master servers which keep in sync by an "out of band" protocol. Most of these instances use a database backend to enable editing on both master servers simultaneously. Both of these servers can be used by the slaves to transfer the zones.

The DNS community have always recommended to distribute public name servers across multiple AS (Autonomous Systems). When outsourcing the DNS service, chance are that the service provider only reside inside a single AS why it has become prudent to use two or more DNS service providers. Since a service provider provide its own master accompanied by  its own slaves, you will end up with a multi master/multi slave infrastructure. In this type of setup, the different master/slave infrastructures operate independent of each other and provide a high degree of availability but with an increased complexity keeping the different infrastructures in sync.

Since the two (or more) infrastructures operates independently, the SOA serial numbers will probably differ between the infrastructures.