Secondary DNS

The Domain Name System, known in short as DNS, is a globally dis­trib­uted system for trans­lat­ing Internet domains into IP addresses. The DNS delivers an IP address cor­re­spond­ing to a domain name and therefore acts as a kind of “address book” for the Internet. Using this analogy, an IP address is equiv­a­lent to a postal address, and this is where “packages” of in­for­ma­tion are sent to. Here are a few examples of DNS queries:

Due to the central im­por­tance of the DNS, it makes sense to keep DNS in­for­ma­tion dis­trib­uted re­dun­dant­ly across different systems. In this way, the in­for­ma­tion remains ac­ces­si­ble even if in­di­vid­ual com­po­nents of the DNS fail. Fur­ther­more, the ge­o­graph­i­cal proximity of a server is crucial for the speed of the responses. In a redundant system, a dis­tinc­tion is made between one source and possibly several copies. In practice, this kind of setup requires a mechanism to adjust the redundant copies when the source changes.

A basic mechanism for dis­trib­ut­ing DNS in­for­ma­tion for a DNS zone to several servers orig­i­nates from a spec­i­fi­ca­tion published by the Internet En­gi­neer­ing Task Force (IETF) in 1996. This specifies how a primary DNS server – pre­vi­ous­ly called a “master” – notifies a group of secondary DNS servers – pre­vi­ous­ly called “slaves” – of a change to the DNS zone. The secondary DNS servers are told to make a request to the primary DNS server to obtain the changes.

There is only one primary DNS server for a DNS zone. This server holds the DNS source in­for­ma­tion for the zone and serves as the entry point for the zone ad­min­is­tra­tor. If changes need to be made to a DNS zone, they are made on the primary DNS server. In contrast, several secondary DNS servers dis­trib­uted around the world may be used to mirror the DNS in­for­ma­tion. A separate DNS provider is often used to host the secondary DNS.

Note that the terms “primary” and “secondary” are used twice in the context of DNS. You may be aware that you can specify the DNS server change in the system settings of your network con­nec­tion. These are often also referred to as “primary” and “secondary”. However, this is an overlap of the term. In terms of a DNS zone, both servers you specify can be secondary DNS servers. Fur­ther­more, you can configure more than two DNS servers at will.

First, both primary and secondary DNS servers are “au­thor­i­ta­tive name servers” for the re­spec­tive zone. This means that the in­for­ma­tion stored for the DNS zone can be trusted entirely. Au­thor­i­ta­tive name servers are therefore different to caching name servers, which merely cache DNS in­for­ma­tion from DNS queries that have already been made.

The dif­fer­ence between primary and secondary DNS servers is mainly ad­min­is­tra­tive. The primary DNS server contains the DNS in­for­ma­tion of a DNS zone in the zone file. Any changes to the zone file are made directly by the zone ad­min­is­tra­tor. By contrast, the zone file of a secondary DNS server cannot be written directly. Instead, any changes to the zone file are obtained from the primary DNS.

When changes are made to the zone file, the secondary DNS servers will be informed of the change and query the changed data. The transfer of DNS in­for­ma­tion between DNS servers is known as zone transfer. In zone transfer, a secondary DNS server is the des­ti­na­tion, while the primary DNS server acts as the source. Note that the same physical server can be the primary DNS server for one DNS zone and a secondary DNS server for another zone at the same time.

The key feature of secondary DNS is that the zone file is trans­ferred to the servers from an external source. Various mech­a­nisms are used for the zone transfer. Fun­da­men­tal­ly reg­u­lat­ing the zone transfer is the DNS entry called “Start of Authority” (SOA). This includes several fields:

• The “MNAME” field contains the IP address of the primary DNS server.
• Fur­ther­more, the SOA record contains several fields that define the intervals at which secondary DNS servers au­to­mat­i­cal­ly request changes from the primary.

We’ll now look at three commonly used DNS con­fig­u­ra­tions below.

In a way, this is the “classic” con­fig­u­ra­tion for dis­trib­ut­ing the DNS in­for­ma­tion of a zone to several au­thor­i­ta­tive DNS servers. A primary DNS server is used, which is specified in the MNAME field of the SOA record. The secondary DNS servers check at regular intervals whether a change has been made to the DNS in­for­ma­tion for their zone and initiate a transfer of the changed data if necessary. In addition, the primary server can notify the secondary DNS servers of changes via a notify statement (see above).

The approach known as “hidden primary” is an in­ter­est­ing variant of the classic primary/secondary con­fig­u­ra­tion. However, here the primary server works secretly – as a hidden primary. The server specified in the MNAME field of the SOA record is not the actual primary server. Therefore, the secondary DNS servers cannot request changes to the DNS zone on their own but must be ex­plic­it­ly requested to do so by the hidden primary via a notify statement.

A popular approach is to configure a computer in the local network as a DNS server and use it as the hidden primary. This has two immediate ad­van­tages:

• Changes to the zone file can be made locally.
• All incoming DNS traffic is handled by the secondary DNS servers.

For this approach, it is suitable to encrypt the com­mu­ni­ca­tion between the secondary DNS servers and the hidden primary with the en­cryp­tion tech­nol­o­gy DNSSEC.

This con­fig­u­ra­tion is a more recent de­vel­op­ment. Several DNS servers that are au­thor­i­ta­tive for a DNS zone are used, all of which contain the source data. There is no zone transfer between them, and therefore there is no secondary DNS in the true sense of the concept. Every change to the DNS zone requires a co­or­di­nat­ed alignment of the primary DNS servers. Pro­pri­etary systems are used for this purpose. For example, imagine an external system with GUI and API that is used to change the DNS in­for­ma­tion and dis­trib­ute the changes.

The benefits of using secondary DNS are many. To un­der­stand them better, let’s imagine that there was only one DNS server for a DNS zone. This con­fig­u­ra­tion would have the following negative effects, among others:

• Users further away from the primary DNS server would ex­pe­ri­ence a delay in responses compared to users closer by.
• Secondary DNS ensures per­for­mance when answering DNS queries.
• A failure of the primary DNS server would mean that the au­thor­i­ta­tive in­for­ma­tion for the DNS zone would suddenly no longer be available.
• Secondary DNS provides re­dun­dan­cy and high avail­abil­i­ty of the DNS in­for­ma­tion.
• An increase in the number of DNS queries received would overload the primary DNS server after a certain point.

In this case, the secondary DNS leads to the dis­tri­b­u­tion of the load and to the high avail­abil­i­ty of the DNS in­for­ma­tion.

As you can tell, a con­fig­u­ra­tion without secondary DNS would be highly vul­ner­a­ble to technical errors and cyber-attacks.

The dis­tinc­tion between primary and secondary DNS is mainly ad­min­is­tra­tive. An external observer cannot con­clu­sive­ly determine whether an au­thor­i­ta­tive DNS server is a primary or secondary server. Fur­ther­more, the same server can be primary DNS for one zone and secondary DNS for another zone. Even the MNAME field of the SOA record does not help in de­ter­min­ing this, because the actual primary DNS server can be operated as a hidden primary.