Principles of DNS synchronization
Synchronizing a domain’s DNS servers
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.
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.
DNS (Domain Name Services) in detail
The DNS service, which stands for Domain Name Services, was born of the desire to facilitate and standardize the process of identifying resources connected to computer networks such as the Internet. Since machines can only communicate by exchanging IP addresses that are difficult for humans to memorize, DNS acts like a telephone directory, providing the correspondence between a machine’s name and its IP address. So, when we want to connect to a computer whose host name we know, we query a DNS server, which returns the IP address corresponding to that name.
DNS is a distributed, hierarchical model, and its implementation requires several servers to individually handle the translation of complementary parts of the name space, in order to make the processing of requests more flexible. These parts, called zones, are in fact name domains whose administration is defined and assigned to one or more servers.
The source domain from which name domains are derived is called the Root domain. The Root domain is managed by 13 DNS servers named ” <x>.root-servers.net”, where <x> is a letter from ‘a’ to ‘m’. These root servers are managed by different organizations appointed byICANN (VeriSign, USC-ISI, Cogent, UMD, NASA-ARC, ISC, DOD-NIC, ARL, Autonomica, RIPE, ICANN and WIDE). To ensure that service is maintained, these servers are actually redundant, either locally or in a distributed manner. In the latter case, the Anycast routing technique is used to associate the IP address of a root server with several geographically distant machines, enabling the load of requests to be distributed transparently. For example, the “c.root-servers.org” root server is managed by the Cogent company and is actually made up of 6 servers spread around the planet. For more information on roots servers, visit http://root-servers.org/
The domains adjacent to the root domain are known as Top Level Domains (TLDs). They define the nature of the organizations and their geographical origin. The ‘com’ TLD, the most widespread, is managed by Verisign on 13 DNS servers. AFNIC currently manages 3 TLDs: ‘fr’, ‘re’ and ‘tf’. The list of 295 existing TLDs is known to all root servers.
Finally, second-level domains (SLD) describe their name or title more precisely. At second-level domains, thousands of other servers are called upon to meet IP address translation needs.
The terminal level (furthest from the root) is the machine’s host name. In this way, a machine on the Internet can be easily identified by its host name and the chain to which it belongs. The concatenation of root, TLD, SLD, subdomains and host name separated by a dot is called a Fully Qualified Domain Name (FQDN). The size limit for an FQDN is 255 characters. For example: the machine used as a mail server at Oktey is called mail within Oktey and “mail.oktey.com” on the Internet.
ICANN justifies limiting the number of root servers to 13 with a technical argument: using more than 13 root servers would result in some DNS queries being answered by more than 512 bytes. The DNS application protocol operates on top of the UDP transport protocol, which is limited to 512 bytes of data. The widespread use of TCP instead of UDP, used for synchronization between DNS servers, would result in DNS servers being overloaded.
To give you a better understanding of the mechanism presented, the following diagram describes the principle of a DNS query. In the example, the user symbolized at top left wishes to access the web server on the machine: “mail.oktey.fr”. We’ll only analyze DNS traffic in this example, and assume that the local DNS server doesn’t have the required information cached (in memory), otherwise it would respond directly to the request.
The commands used to query the DNS service are ‘nslookup’ under Windows and ‘dig’ or ‘host’ under Linux. If you don’t know the IP of the machine being contacted via the “/etc/hosts” name file, the DNS resolver uses the DNS server(s) mentioned in “/etc/resolv.conf” (or the network configuration under Windows) to carry out its queries. For each of these steps, we’ll describe the commands under Linux in the form: #commande and the equivalent under Windows in the form: >command. Answers will be produced for Windows commands, to avoid making the article unnecessarily long.
1) The user’s workstation is configured to use the resolver, which will direct the request to the “Local DNS server”, generally corresponding to the IP of the company’s DNS server.
# dig mail.oktey.com
> nslookup
> mail.oktey.com
If the local DNS server has the answer in its cache, it will immediately answer the result, otherwise it will continue by successively querying all DNS servers, the phases described below: (2) Root, (3) DNS of FR, then (4) DNS of oktey.fr.
2) The local DNS server has no knowledge of the IP assigned to the “mail.oktey.fr” server. It must therefore retrieve the information from the “oktey.co.uk” servers. To do this, it first contacts the root servers to find out who manages “fr”. The list of root servers is known to all DNS servers, and is the only hard-coded information on DNS servers.
For a list of root servers :
# dig . NS
> nslookup
> set q=NS
> .
(root) nameserver = g.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = b.root-servers.net
(root) nameserver = c.root-servers.net
(root) nameserver = j.root-servers.net
(root) nameserver = h.root-servers.net
(root) nameserver = a.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = m.root-servers.net
(root) nameserver = k.root-servers.net
(root) nameserver = i.root-servers.net
a.root-servers.net internet address = 198.41.0.4
a.root-servers.net AAAA IPv6 address = 2001:503:ba3e::2:30
b.root-servers.net internet address = 192.228.79.201
c.root-servers.net internet address = 192.33.4.12
d.root-servers.net internet address = 128.8.10.90
e.root-servers.net internet address = 192.203.230.10
f.root-servers.net internet address = 192.5.5.241
f.root-servers.net AAAA IPv6 address = 2001:500:2f::f
g.root-servers.net internet address = 192.112.36.4
h.root-servers.net internet address = 128.63.2.53
h.root-servers.net AAAA IPv6 address = 2001:500:1::803f:235
i.root-servers.net internet address = 192.36.148.17
i.root-servers.net AAAA IPv6 address = 2001:7fe::53
j.root-servers.net internet address = 192.58.128.30
For your information, the response shows that 4 out of 13 root servers have IPv6 addressing. For the next request a root server will be used at random among the 13 available, in our example we will use c.root-servers.net [192 .33.4.12].
Root server query to find out who manages ‘fr’ :
# dig @192.33.4.12 fr NS
> nslookup
> set q=NS
> server 192.33.4.12
> fr
fr nameserver = d.ext.nic.fr
fr nameserver = f.ext.nic.fr
fr nameserver = e.ext.nic.fr
fr nameserver = d.nic.fr
fr nameserver = a.nic.fr
fr nameserver = g.ext.nic.fr
fr nameserver = c.nic.fr
a.nic.fr internet address = 192.93.0.129
a.nic.fr AAAA IPv6 address = 2001:660:3005:3::1:1
c.nic.fr internet address = 192.134.0.129
c.nic.fr AAAA IPv6 address = 2001:660:3006:4::1:1
d.ext.nic.fr internet address = 192.5.4.2
d.ext.nic.fr AAAA IPv6 address = 2001:500:2e::2
d.nic.fr internet address = 194.0.9.1
d.nic.fr AAAA IPv6 address = 2001:678:c:1::1
e.ext.nic.fr internet address = 193.176.144.6
e.ext.nic.fr AAAA IPv6 address = 2a00:d78:0:102:193:176:144:6
f.ext.nic.fr internet address = 194.146.106.46
f.ext.nic.fr AAAA IPv6 address = 2001:67c:1010:11::53
g.ext.nic.fr internet address = 204.61.216.39
g.ext.nic.fr AAAA IPv6 address = 2001:500:14:6039:ad::1
AFNIC uses 7 DNS servers, 3 are physically on AFNIC networks in France, and 4 (the ‘ext’ sub-domains) are outside the AFNIC network.
3) A request is then sent to AFNIC’s DNS servers to find out which are the DNS for the zone: ‘oktey.fr’. In this example, we’ll randomly use the d.nic.fr server [194 .0.9.1].
# dig @194.0.9.1 oktey.fr NS
> nslookup
> set q=ns
> server 194.0.9.1
> oktey.fr
oktey.fr nameserver = dns.oktey.net
oktey.fr nameserver = ns.oktey.net
4) Finally, the final DNS request is made directly to one of the DNS servers managing the ‘oktey.fr’ domain, the “authoritative” DNS. The record type we’re interested in is no longer NS but A (or CNAME). The IP address of : dns.oktey.net’ is 213.251.128.136, hence the query below.
# dig @213.251.128.136 mail.oktey.fr A
> nslookup
> set q=A
> server 213.251.128.136
> mail.oktey.fr
Nom : mail.oktey.fr
Address: 87.248.120.148
To carry out this last request, it was necessary to find the IP of the ‘dns.oktey.net’ server. If the information wasn’t in the cache, it was necessary to contact DNS, root to find out who manages .net, then oktey.net, then dns.oktey.net, i.e. 3 additional requests.
At each stage, one of the returned DNS servers was randomly selected for the next query. It is therefore vital that all DNS servers systematically return the same response to an identical query. DNS servers in the same zone must therefore be synchronized with each other.
The step-by-step breakdown we have just described can be displayed directly using the following dig command: #dig +trace +all mail.oktey.fr
We introduced you to the DNS service in this article, because e-mail (like the web) uses the DNS service as its foundation. We’ve noticed that very often e-mail problems actually stem from DNS issues. A good understanding of how DNS works is often the key to solving many e-mail problems.
