SOA Records: The Basis of Every Zone File

For any internet user, it goes without saying that they need to enter a website’s URL in the browser in order to arrive at their desired homepage. They don’t notice that the computer actually es­tab­lish­es the con­nec­tion with an IP address. This is due to the Domain Name System (DNS) and its name res­o­lu­tion function. Here, the domain’s name is resolved into the required number sequence. For the system to function, the name servers must have zone files. In turn, these simple text files contain numerous DNS records that enable the DNS in the first place.

The most well-known, of course, are A records. This is because the actual name res­o­lu­tion occurs in these records. In addition, there are also PTR records, which enable reverse DNS, or MX records for email com­mu­ni­ca­tion. But what are SOA records intended for?

The DNS is a de­cen­tral­ized, hi­er­ar­chi­cal system: Name servers don’t supply in­for­ma­tion to just any server on the internet, but to those located in an allocated zone. For this purpose, the DNS server ad­min­is­ters zone files. These are simple text files in which all of a zone’s DNS records are listed. In order to establish the different au­thor­i­ties, each zone file must contain an SOA record. SOA thus stands for Start of Authority. The record ac­cord­ing­ly provides in­for­ma­tion on a number of issues, such as whether or not the addressed server is even re­spon­si­ble for the request.

The SOA record is es­pe­cial­ly important in the case of server clusters. Instead of shoul­der­ing the load for all requests, the requests are dis­trib­uted among different devices. In order for the zone files to remain current on all servers, a zone transfer must be performed regularly. To achieve this, the “slaves” (i.e. servers situated lower on the hierarchy) syn­chro­nize their data with that of the “master” server. The way the zone transfer is supposed to proceed is regulated by the SOA record. For this purpose, this type of DNS record receives various types of in­for­ma­tion.

DNS records generally consist of several fields. In these you’ll find all the relevant in­for­ma­tion. In com­par­i­son to other types, the SOA record has many fields:

• <name>: zone name
• <class>: network class
• <type>: record type
• <mname>: master name
• <rname>: email address for the re­spon­si­ble ad­min­is­tra­tor
• <serial>: in­cre­men­tal serial number that specifies the zone file version
• <refresh>: time spec­i­fi­ca­tion when a slave must request the current master version
• <retry>: time spec­i­fi­ca­tion when a slave is supposed to again perform a failed request attempt
• <expire>: time spec­i­fi­ca­tion from which a slave does not release further in­for­ma­tion in the absence of feedback from the master
• <minimum>: time spec­i­fi­ca­tion for how long in­for­ma­tion may be retained in a cache

The first three fields are typical for DNS records. The zone name is a domain name in the form of a Fully Qualified Domain Name (FQDN). This means that the spec­i­fi­ca­tion – different from what you may recognize from a URL – ends with a period. The reason for this is that an FQDN shows the domain’s complete hi­er­ar­chi­cal structure, which has a root directory at the end. This is of course empty, which is why only the sep­a­rat­ing period remains. You’ll find this notation in all DNS domain names as well as in the MNAME and RNAME fields.

The class field has only his­tor­i­cal relevance and for this reason is simply omitted in many cases. When DNS was being developed, there was also the Hesiod (HS) and Chaos (CH) projects. Both are now obsolete, which is why only the internet with the IN ab­bre­vi­a­tion can be utilized in this field. The type refers to the kind of DNS record being used, so in this case, SOA.

MNAME is also known as primary master and specifies which server is located above the slave. This is so that the name server is defined through which the sub­or­di­nate server must attempt a zone transfer. When for­mat­ting the email address in the RNAME field, there are some specific features to take into account. An @ symbol is not permitted in the notation. Instead, a period separates the local part (e.g. the user name) from the domain. Should there be a period before the @ symbol in the original email address, one must denote this with a backslash (\).

The serial number must be in­cre­men­tal­ly increased with each change made to the zone file. Two versions have become es­tab­lished. On the one hand, a simple process can begin at 1 and with each change to the serial number be increased by 1. With this option, the number of changes already made can be read from the serial number.

The other option is choosing a date format: YYYYM­MD­DVV. One begins with a four-digit year spec­i­fi­ca­tion, followed by the month and day (each com­pris­ing two positions) and ends the spec­i­fi­ca­tion in turn with a two-digit version number. In this format, one can thus identify the date the version was created. With each change that is made on the same day, the version number increases by one. On a new day, the serial number adjusts to the ap­pro­pri­ate place and the version number is reset to 00.

The SOA record ends with three to four time spec­i­fi­ca­tions – each in seconds. The first field (“Refresh”) specifies the time lag until the slave again asks the master for a current version of the zone file. Should this request go unan­swered, the “Retry” field regulates when a new attempt is to be carried out. It is important for this spec­i­fi­ca­tion to be smaller than the previous one.

If the server that’s situated lower in the hierarchy receives no further replies, the third time spec­i­fi­ca­tion (“Expire”) de­ter­mines how long the zone file may still be used before the server refuses DNS in­for­ma­tion delivery. Should the server continue to send old zone file data to the clients sub­mit­ting requests, it may no longer be valid. This may lead to con­nec­tion issues and security risks.

The “Minimum” field completes the record. This cor­re­sponds to the time to live, as you may be familiar with from other DNS record types. It specifies how long a client may hold the requested in­for­ma­tion in the cache before a new request must be sent. Most of the time, however, the TTL is set for the entire zone with the $TTL directive. Once this is done, it doesn’t have to be performed sep­a­rate­ly for each entry. The zone name can also be de­ter­mined as early as the beginning of the file, then assigned the $ORIGIN directive.

The entry always appears at the beginning of the zone file.

The fields can simply be listed one after the one on a line. While this is not very complex with other entry types, the SOA record is rather com­pre­hen­sive in com­par­i­son. In order to create more clarity, the fields are usually arranged in nests and un­der­neath each other.

This notation is used to determine the TTL and domain name upfront. The @ symbol at the beginning of the record refers to the origin directive. In order to nest the time spec­i­fi­ca­tions and to divide them among several lines, paren­the­ses are in­tro­duced.

No zone file is valid without an SOA entry at the beginning. In practice, SOA records look like this:

In this zone file snippet, you can see how – in order to make the placement clearer – we have entered more in­for­ma­tion than just the SOA record. The file begins with the domain name spec­i­fi­ca­tion (in this case, example.org) and the TTL. This is then followed by the SOA record. Because we have already de­ter­mined the zone in the $ORIGIN directive, the @ symbol is suf­fi­cient here as a reference.

The zone’s (notional) master follows im­me­di­ate­ly after the network class and record type spec­i­fi­ca­tions, which are in turn followed by the admin email address. The period is enabled through the backslash – in this case a masking character. The next period then replaces the @ symbol for the actual address; the following one, as usual, defines the top-level domain (TLD). Using a bracket, you can open the nested area which can then be divided among several lines. However, it is also possible to write all values behind one another and to only separate them with empty spaces.

In this example, we have written the de­f­i­n­i­tions for the specific values behind them. These are only comments that can be selected them­selves or simply omitted. In the case of DNS records, a semicolon can be used to mark those comments that are solely intended for human users.

The bracket must be closed at the end of the SOA record.

Sub­se­quent­ly, we have also included a NS record and an A record in the zone file example. You can see that the SOA record must be placed before all the other records – but not before the domain and TTL di­rec­tives.

The request is performed under “Question”. The request result can be found under “Answer”. In the answer’s data field, you can recognize the master server, the re­spon­si­ble person’s email address and the time spec­i­fi­ca­tions. What is no­tice­able here is that the last value (minimum) cor­re­sponds to the spec­i­fi­ca­tion under TTL down to a second. This second has pre­sum­ably already passed, which is why it results in a minimum dis­crep­an­cy.

The spec­i­fi­ca­tion under the “type” item il­lus­trates a specific feature: Instead of the SOA des­ig­na­tion, you can find the number 6 both in the request and reply. The Internet Assigned Numbers Authority (IANA) has assigned each DNS record type with an in­di­vid­ual value. Even record types that are not used or are no longer used have a number. This results in a nearly seamless list of the different types. In this system, SOA records have the number 6.