Principles of DNS synchronization

The DNS system divides the name space into zones. These zones store information relating to one or more domains. First and foremost, a zone is a storage database containing RR(Resource Records) for a DNS domain name. If a sub-domain is created, it may be managed by the parent domain’s zone, or by a zone of its own.

The following figure illustrates the zone concept:

To create the sample sub-domain, you need to register it in the oktey.com zone or delegate it to the sample.oktey.com zone. The sample.oktey.com zone must be created for delegation.

DNS replication principle

Each zone has its own (unique) main DNS server, which has read-write access to the zone’s original data and acts as the zone’s update point. This zone will be replicated in its entirety by the so-called secondary servers.

A zone’s secondary DNS servers provide load balancing and fault tolerance. They keep a read-only copy of the zone data that is regularly transferred from the main DNS server. It’s entirely possible to configure DNS clients to query secondary DNS servers instead of, or in addition to, the main DNS server for a zone, thereby reducing demand on the main server and ensuring that DNS queries for the zone are answered even if the main server is unavailable. In general, requests are distributed across all servers.

In DNS synchronization, the zone’s main DNS server will act as source for the zone (process A). This means that it will be able to authorize the update: it will be referred to as the master server.

The synchronization request is always made by a secondary DNS server to the master server, since it cannot update the zone data on its own due to its read-only rights. This requesting server is referred to as a slave server.

Note: it’s possible that the same secondary server that played the role of slave will be the master server in another DNS replication process (process B).

Replication process

An SOA(Start Of Authority) request in UDP protocol (1) is sent from the slave server. The master server replies with a copy of its SOA record. The slave server compares the version number of its SOA record with the one it has received. If it’s different, it makes a TCP (2) zone transfer request to the master server for DNS synchronization.

The use of the TSIG(Transaction SIGnature) security protocol authenticates the master/slave transaction and ensures the integrity of the data received.

There are two types of zone transfer: total (AXFR), where a complete copy of the zone is made, and incremental (IXFR), where only modifications are replicated.

The incremental transfer process is preferred because it generates less network traffic and is faster.

A zone must be present on several DNS servers to guarantee availability and fault tolerance when resolving name queries. This is why it’s important to replicate the zone on other servers and synchronize all copies on each server.

A DNS desynchronization problem in MX fields, for example, could lead to e-mails being sent to different mail servers. DNS synchronization between the main server and the secondary server therefore guarantees consistency of information, i.e. the uniqueness of the response to a DNS query.

It is possible to implement a broadcast mechanism to notify a specific set of secondary servers for a zone of an update using the DNS notify function. The alerted servers can then initiate a zone transfer, so they don’t have to wait for the refresh time to expire.

Main DNS server and SOA

The aforementioned SOA field is one of the RR records present in the zone and provides information on the main DNS server that has authority over the zone, the technical contact’s e-mail address (with @ replaced by a dot) and expiration parameters.

Other RR records include A for the host name of the machine, CNAME for the alias, NS for the name server and MX for the mail server. A list of all RR registrations can be found on the IANA website: http: //www.iana.org/assignments/dns-parameters

An example of an SOA record with the nslookup command would be :
> nslookup
> set querytype=SOA
> oktey.com
primary name server = ns1.oktey.com
responsible mail addr = info.oktey.com
serial = 2009032780
refresh = 7200 (2 hours)
retry = 1800 (30 mins)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

Explanation of the different parameters of an SOA record :

serial indicates the version number of the zone database. This number must be incremented if the database is modified. In general, this number will consist of the date in the format YYYYMMDD followed by a two-digit number.

refresh indicates the time to wait for a new update request from the zone’s secondary server. Before this time expires, the secondary server requests a copy of the SOA record from the main server. A comparison of the version number with its own SOA record is made to see if there is a need for zone transfer.

retry indicates the waiting time before a new failed zone transfer attempt.

expire indicates the database validity time during which no update could be launched (including refresh and x retry), i.e. during which at least one zone transfer was performed. If this period expires, the secondary server will no longer respond to DNS requests, as it will consider its database unreliable.

default TTL indicates the validity time applied by default to all RRs, which corresponds to the retention time in the DNS data cache. However, it is possible to define a specific TTL for a specific RR. In this case, we simply speak of TTL. Of the TTLs defined, the smallest characterizes the ‘Minimum TTL’, which becomes the lower limit of the TTL field.

The SOA record for the root zone is given by :
> nslookup
> set querytype=SOA
> .
primary name server = a.root-servers.net
responsible mail addr = nstld.verisign-grs.com
serial = 2011010900
refresh = 1800 (30 mins)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

When querying the root zone for the SOA record, it’s interesting to note that the main server serving as master for DNS replication is designated by the root server a.root-servers.net, whose management is attributed to Verisign, as is the email address of the root zone manager: nstld@verisign-grs.com. In fact, this used to be the case, i.e. root servers got their updates from root server A. Now, there’s a hidden, non-public master server from which all other root servers (including Server A) get their copy of the root zone.

Root servers using the Anycast technique also propagate these updates to their Anycast mirrors. For more details, please see the article on the detailed operation of the DNS protocol: https: //www.altospam.com/actualite/2011/01/principe-de-fonctionnement-detaille-du-service-dns/