The SOA Record Explained in the DNS zone file

A zone file is a DNS database file. It stores data for a particular domain. In this file, the SOA record defines the authoritative name server for the domain and configures its properties and characteristics. The authoritative name server is considered the best and most authoritative source of information for the domain specified in the domain-name field.

Example DNS zone file

We will use the following example zone file to understand the SOA record and its fields.

Key points: -

• We can add only one SOA record in a zone file.
• We need to add it before adding other resource records.
• We can add it at the beginning of the file just after the TTL and ORIGIN directives.

The SOA record syntax

The SOA record uses the following syntax.

domain-name TTL class-type record-type name-server e-mail-address serial-number refresh-time retry-time expiry-time negative-cache-TTL

Let us understand this syntax field-by-field.

The domain-name Field

This field specifies the domain or zone name. The name server whose name we specify in the name-server field becomes the authoritative name server for the domain or zone whose name we specify in this field.

You can use four values here: a fully qualified domain name, a relative name, a single @ character, and a blank space.

1. If you specify an FQDN name, DNS uses the name as it is.
2. If you specify a relative name here, DNS uses the $ORIGIN directive's value to convert it into the FQDN name.
3. If you specify the character @ here, DNS replaces it with the value of the $ORIGIN directive.
4. If you use a blank space here or leave this field empty, DNS uses the value of the name field of the previous record. If the previous record is not available, it uses the value of the $ORIGIN directive.

In our example, we used the character @ in the domain-name field. Because of this, it will use the $ORIGIN directive's value in this field.

The TTL Field

This field defines the time for which other name servers or resolver systems can cache this record. If we leave this field empty, DNS automatically fills its value from the $TTL directive.

The class-type Field

This field defines the class of the record. There are three classes: IN (Internet), CH, and HS. Currently, only the IN class is used. CH and HS classes are used in special cases for specific reasons.

The record-type Field

This field defines the type of record. The type of this record is SOA. For other types of records, you can check other tutorials of this series.

The name-server Field

This field defines the authorized name server for this domain. In our example, we authorized the name server ns.example.com. for the domain. This field only defines the authorized name server for the domain. It does not map an IP address with it. To map an IP address with the authorized name server, we need to create a host record for it.

The email-address Field

This field defines the administrative email address of the domain. You can use any valid email address in this field. Generally, administrators use the email address hostmaster here. It describes the purpose of this field.

In other configuration files, the character @ is used as the separator in the email address. In a zone file, the character @ has a special meaning. DNS replaces it with the $ORIGIN directive's value. If we specify the email address as [email protected], DNS will read it as hostmaster.example.com.example.com.

Because of this, DNS uses a dot (.) as a separator. In our example, we used the email address hostmaster.example.com. as the administrative email address. DNS will read this address as [email protected].

Fields in the parenthesis

A zone file uses lines to store resource records. For each record, it uses a separate line. If you want to create a record in multiple lines, you need to use a parenthesis. DNS process everything you put between an opening parenthesis and a closing parenthesis as a part of the line. Administrators use this feature to make the SOA record more human-readable.

For simplicity, they keep all fields used by a slave name server inside a parenthesis. A slave name server fetches zone files from the master name server. This process is called a zone transfer. Fields specified in the parenthesis are mainly used by slave or secondary name servers to define and manage zone transfer intervals.

Inside the parenthesis, they use a separate line for each field. They also add a comment with each field explaining the value stored in the field. When processing this record, DNS ignores all comments and appends all fields written in parenthesis to the line which contains the opening parenthesis.

DNS will see our example SOA record as the following.

@ IN SOA ns1.example.com. hostmaster.example.com.    2023013100   12h   15m   3w  2h

The serial-number Field

The serial-name field defines a serial number. This number is used for many purposes. The most common use of this number is to track the update or change made in this file. Each time when you make a change in this file, you need to update this number. You can use any number in the range of 0 to 4294967295.

Usually, administrators use the current date in the form of YYYY-MM-DD and an incremental sequence number in the range of 00 to 99 to generate a unique and updated serial number for every change they make in the file. For example, if we expend the serial number 2023013100 using this technique, we get values 2023 - 01 - 31 - 00. These values show this file was last updated on 31 January 2023. A 00 in the sequence field shows that this file was updated only once on 31 January 2023. If administrators update a zone file more than once per day, they can use incremental sequence numbers for every update. For example, serial number 2023013103 shows the file was updated three times on January 31, 2023.

The refresh-time Field

This field sets the refresh time. The slave name server uses this time to determine how quickly it should check the master name server for an update.

A slave name server uses zone transfer requests to obtain zone files from the master name server. The slave name server uses this time to set an interval between two zone transfer requests. When this time expires, the slave server asks the master name to provide only the SOA record. It compares the serial number of the SOA record stored in the zone file it has with the serial number of the SOA record it received from the master name server. If the serial number of the SOA record it received from the master server is higher than the serial number of the SOA record it has, it sends a zone transfer request to the master name server. In response, the master server provides the complete zone file to the slave name server.

In our example, we configured the refresh time to 12 hours (12h). Because of this, if we configure a slave name server for this domain, it will ask the master name server to provide the SOA record every 12 hours.

Let's understand it through an example. The slave name server tries to reach the master name server at 3.00 AM. If it connects, it will try again at 3.00 PM. The current refresh cycle is set at 12h. Because of this, it will try every 12 hours.

The retry-time Field

This field defines the retry interval in seconds. If the slave name server fails to connect with the master name server, it can try again after this time.

In our example, we configured the retry time to 15 minutes (15m). Because of this, the slave name server will try to connect to the master name server every 15 minutes if it fails to connect to the master name in a refresh cycle.

Let's understand it through an example. The slave name server tries to reach the master name server at 3.00 AM. If it connects, it will try again at 3.00 PM. But if it fails, it will try again at 3.15 AM. Then at 3.30 AM. Then at 3.45 AM and so on until it gets a reply from the master name server or reaches the expiry time.

The expiry time Field

This field defines the time after which the zone records are assumed to be no longer valid. When the refresh time expires, the slave name server tries to reach the master name server. If it fails, it tries to reconnect every retry period until the expiry time. If it succeeds on any try, it resets the refresh and retry times. If it fails to contact the master server till the expiry is reached, it stops working as a slave name server for the zone.

Let's understand it through an example. The slave name server tries to reach the master name server at 3.00 AM on 1 Jan 2023. If it connects, it will try again at 3.00 PM. But if it fails, it will try again at 3.15 AM. Then at 3.30 AM. Then at 3.45 AM and so on until 3.00 AM on 22 Jan 2023 (1 Jan + 3 weeks = 22 Jan). After this time, it will not resolve queries for the domain.

A slave name server resolves queries for the zone when the master name server is down. It resolves queries for the domain until the master is up or the expiry is reached. After the expiry, it does not resolve queries for the domain. At this point, since both the master name server and the slave name server are not resolving queries, the zone is considered dead.

The negative-cache-TTL Field

Resolver systems use this value to store negative responses. This value applies to all records served from this zone file. DNS provides this value in each answer. Let's take an example. Suppose, a resolver system asks ns1.example.com to resolve the name xyz.example.com. The ns1.example.com name server checks this zone file. Since this zone file has no entry for the name xyz.example.com, it returns a Name Error (NXDOMAIN) indicating the requested name does not exist and can't be resolved. It also includes the negative-cache-TTL field's value in the error.

The resolver system saves the answer in the cache and does not send a query to solve the same name again until the negative cache-TTL expires. In our example, the resolver system will not send a query to ns1.example.com to resolve the name xyz.example.com until 2 hours, starting from the time it received the response, expire. For example, if it receives a negative response at 2.00 PM, it will not retry until 4.00 PM for the same name.