DNSmonitor KB - DNS Tutorials

DNS Tutorial part 2

DNS infrastructure

In part one of our DNS tutorial we described how the the domain name space looked and worked. We described how everything is connected with delegation records in parent zones pointing resolvers to their next step on their journey to find the servers authoritative for a specific zone.

In this part we will take a look at the DNS infrastructure, and especially the authoritative DNS where we keep our domains and how they work.



The zone content is edited on the Master DNS and is from where the zone content is distributed. A Master, also known as "Primary" can respond to non-recursive DNS queries.


A Slave server holds an exact replica of the Masters zone data. The Slave servers obtain the zone replica by means of zone transfer. Slave Servers are also known by the term "Secondary".


A stealth server is a DNS Master or Slave server that is not listed in the zones NS or SOA resource records. This way the server will not be found by DNS resolvers and will not receive any queries unless they are artificially directed to the stealth server.


A notify message is sent to the Slave servers as soon as new zone content is available on the Master. This happens when an administrator have updated the zone content, a dynamic record has been updated (this include resource record signatures and public keys for a DNSSEC signed zoned).


Asynchronous zone transfer is a zone transfer protocol where the full zone content is transfered from a Master to a Slave. A zone transfer is initiated from the Slave servers, usually after receiving a Notify message.


Incremental zone transfer is a zone transfer protocol where only the updated records are transfered. Otherwise the work identical to an AXFR.

SOA Serial

The serial number for the zone is stored in the SOA resource record and is used by the Slave servers to determin if a one transfer is needed or not.

DNS views

An "easy" way to separate DNS responses based on query source address. Common examples are Indernal view, DMZ view and External view.

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...

Building DNS infrastructure

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.

Basic DNS setup

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.

Example 1
NS RR set:
example.com.   IN    NS    dns1
example.com.   IN    NS    dns2
example.com.   IN    NS    dns3

SOA Master name: dns1

Hidden Master

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.


Example 2
NS RR set:
example.com.   IN    NS    dns2
example.com.   IN    NS    dns3

SOA Master name: dns1

To completely hide the DNS Master from Internet exposure we will need to replace the SOA Master name with one of the Slave servers, as shown in Example 3.

This will hide the Master (who still need a host record) but it will create a new problem that may need to be dealt with: Dynamic DNS update requests. We will circle back to that later in this tutorial.

Example 3
NS RR set:
example.com.   IN    NS    dns2
example.com.   IN    NS    dns3

SOA Master name: dns2

Designs with multiple masters

Multiple Masters are usually implemented to increase resiliency. The downside is that in many circumstances the also add complexity. This can be a tricky situation to solve because when complexity increases usually a degradation of security follows.

Below are a few successful design where multiple masters are used.

Microsoft AD

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.

NS RR set:
ad.example.com.   IN    NS    dc1
ad.example.com.   IN    NS    dc2
ad.example.com.   IN    NS    dc3

SOA Master name: dc1/dc2/dc3 depending on which DNS responding to the query.

A simple Multi master concept

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.

NS RR set:
example.com.   IN    NS    dns2
example.com.   IN    NS    dns3

SOA Master name: dns0/dns1 depending on setup.

A more complex Multi master concept

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.

NS RR set:
example.com.   IN    NS    dns1
example.com.   IN    NS    dns2
example.com.   IN    NS    dns3
example.com.   IN    NS    dns5
example.com.   IN    NS    dns6

SOA Master name (A): dns0
SOA Master name (B): dns4.