SOA Record Explained: Reading Start of Authority DNS Records

An SOA (Start of Authority) record is the most critical DNS record in any DNS zone. It serves as the "authority" for the entire zone, defining which nameserver is the primary source, establishing synchronization rules for secondary nameservers, and controlling various caching behaviors. Every DNS zone must have exactly one SOA record, which specifies the primary nameserver, the zone administrator's contact information, version control via serial number, and timing parameters for zone transfers and cache management. This article explains all seven fields of the SOA record, how to read them, and why the serial number is critical to maintaining zone integrity across your DNS infrastructure.

What Is an SOA Record and Why It Matters

An SOA (Start of Authority) record is a foundational DNS record that declares which nameserver is the authoritative source for a specific DNS zone, and it orchestrates the synchronization of zone data between primary and secondary nameservers. In a typical DNS infrastructure with redundancy, there is one primary nameserver holding the authoritative zone file and one or more secondary nameservers maintaining copies for failover and load distribution. The SOA record acts as the control mechanism governing how frequently secondaries check for updates, how they handle failures, and what constitutes "stale" data.

The SOA record serves multiple critical functions. First, it designates the MNAME (Master Name Server), which is the primary nameserver that secondary servers contact to pull zone data. Second, it records the RNAME, the email address of the zone administrator (formatted with a dot replacing the @ symbol). Third, it includes a Serial Number that acts as a version identifier—secondary servers compare their serial with the primary's serial to determine if an update is needed. Fourth, it defines three timing parameters: Refresh (how often secondaries check for updates), Retry (how long to wait after a failed update before trying again), and Expire (how long secondaries will serve stale data before giving up entirely). Finally, it specifies a Minimum TTL value used for negative caching—storing the fact that a record does not exist—which reduces unnecessary queries for non-existent records.

SOA Record Structure and Field Definitions

Here is a typical SOA record for example.com:

example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. 2024010101 10800 3600 604800 86400

Let's break down each component.

MNAME: Master Name Server

The first field after SOA is MNAME, the Fully Qualified Domain Name (FQDN) of your primary nameserver—in this case, ns1.example.com. (note the trailing dot, indicating a fully qualified name). This server holds the authoritative zone file and is the source that secondary nameservers contact to request zone transfers. The MNAME must point to a server that is actually configured as a nameserver for your zone and that responds to DNS queries. If MNAME is misconfigured, secondary servers will be unable to retrieve zone updates, breaking zone synchronization entirely.

RNAME: Responsible Name (Administrator Email)

The second field is RNAME, which specifies the email address of the person responsible for managing the DNS zone—the DNS administrator. To fit the DNS record format, the email address is encoded in a special way: the @ symbol is replaced with a dot. So hostmaster.example.com. translates to [email protected] in human-readable form. The reason for this encoding is historical—the original DNS specification (RFC 1035) did not support the @ character in zone file syntax, so a dot was substituted. RNAME is not actively used by resolvers but serves as a reference for zone administration and is sometimes read by monitoring systems or scripts.

Serial Number: Zone Version Identifier

The Serial Number is a version identifier for your zone file. Secondary nameservers use serial comparison to determine whether a zone has been updated. When a secondary checks in (during its Refresh interval), it compares the primary's serial with its own cached serial. If the primary's serial is larger, the secondary knows an update occurred and will initiate a zone transfer. The Serial Number must be an unsigned 32-bit integer, ranging from 0 to 4,294,967,295. A widely adopted convention is the format YYYYMMDDNN, such as 2024010101, meaning January 1, 2024, update #1. The NN portion (00–99) allows up to 99 updates per day. The advantage of this format is that it naturally increments over time and is easy for administrators to reason about. However, any monotonically increasing sequence will work; what matters is that every zone edit must result in a higher serial number.

Refresh: Secondary Check Interval

This value specifies how often (in seconds) a secondary nameserver will check whether the primary has updated the zone. It does so by querying the primary's SOA record and comparing serial numbers. A typical value is 10800 seconds, equivalent to 3 hours. This means a secondary will poll its primary every 3 hours. For large, stable zones with infrequent changes, administrators might use a longer interval like 86400 seconds (1 day) to reduce network traffic. For zones that change frequently, a shorter interval like 3600 seconds (1 hour) ensures updates propagate faster. The tradeoff is between overhead and propagation speed.

Retry: Retry Interval After Failed Transfer

If a secondary fails to reach the primary or a zone transfer attempt fails, it will wait this many seconds before trying again. Typical value is 3600 seconds (1 hour), which is shorter than Refresh. For example, if Refresh is 10800 seconds (3 hours) and a transfer attempt fails, the secondary will retry within 3600 seconds (1 hour) rather than waiting the full 3 hours. This mechanism balances resilience (don't overwhelm a struggling primary with constant retries) and responsiveness (don't wait too long before attempting recovery).

Expire: Zone Expiration Timeout

If a secondary cannot contact the primary for an extended period matching this value (in seconds), the zone is considered expired and the secondary will stop serving it. A typical value is 604800 seconds (1 week). This policy prioritizes availability: if the primary is down but the secondary still has cached zone data, the secondary will continue serving it to avoid complete service loss. However, after one week of isolation, the secondary will retire the zone to prevent stale data from being served indefinitely. This is a safety mechanism to handle prolonged primary failures.

Minimum TTL: Negative Cache TTL

This value (in seconds) serves as the Time-To-Live for negative caching—the caching of "does not exist" responses. When a resolver queries for a record that doesn't exist in the zone (for example, nonexistent.example.com), the nameserver returns a negative response. Resolvers will cache this "no such record" result for the period specified by Minimum TTL. A typical value is 86400 seconds (1 day). The purpose is to reduce query traffic for records that genuinely do not exist. Without negative caching, every query for a non-existent subdomain would hit your authoritative nameserver; with it, the resolver stops asking after the first negative answer for a day.

SOA Record Field Reference Table

Field	Purpose	Unit	Typical Value	Example
MNAME	Primary nameserver	FQDN	ns1.domain.com.	ns1.example.com.
RNAME	Admin email (@ becomes dot)	FQDN	hostmaster.domain.com.	hostmaster.example.com.
Serial	Zone version number	Unsigned 32-bit	YYYYMMDDNN	2024010101
Refresh	Secondary poll interval	Seconds	10800	3 hours
Retry	Retry wait after failure	Seconds	3600	1 hour
Expire	Secondary stale timeout	Seconds	604800	1 week
Minimum TTL	Negative caching TTL	Seconds	86400	1 day

How to View an SOA Record Using the dig Command

To inspect the SOA record of any domain, use the dig utility, the standard DNS query tool on Linux and macOS (or nslookup on Windows):

dig SOA example.com

The output will include multiple sections. Look for the ANSWER SECTION, which displays the SOA record:

;; ANSWER SECTION:
example.com.		3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2024010101 10800 3600 604800 86400

For a cleaner output showing only the SOA record without headers, use the +short flag:

dig SOA example.com +short

Output:

ns1.example.com. hostmaster.example.com. 2024010101 10800 3600 604800 86400

To query the SOA record from a specific nameserver (useful for verifying that secondary servers have updated), use the @ syntax:

dig @ns2.example.com SOA example.com

This technique is valuable for troubleshooting zone synchronization issues. If the serial numbers differ across nameservers, it indicates that a zone transfer has not yet completed or has failed. Comparing SOA records from all your nameservers is a quick way to verify zone propagation status.

Serial Number Management: Critical for Zone Updates

The Serial Number is arguably the most critical component of the SOA record. Every time you edit your zone file—adding, removing, or modifying a DNS record—you must increment the Serial Number. Secondary nameservers rely entirely on serial comparison to detect zone updates. If you forget to increment the serial after making changes, secondary nameservers will have no indication that the zone has changed, and they will not pull the updated zone file. As a result, your DNS changes will not propagate to secondary servers, potentially breaking DNS resolution for clients that query those secondaries.

For example, suppose your current SOA serial is 2024010101. You add a new A record to your zone. Before reloading the zone on your primary nameserver, change the serial to 2024010102 (incrementing the last two digits by one). Save the zone file and reload it. The next time a secondary queries the primary for the SOA record, it will see that 2024010102 > 2024010101, recognize that an update has occurred, and initiate a zone transfer to fetch the new zone file. This entire process typically completes within minutes, often faster if your nameserver software supports the DNS NOTIFY mechanism, which signals secondaries immediately when a zone changes rather than waiting for the next scheduled refresh.

Common Mistakes and Prevention

Summary

The SOA record is essential to DNS zone management and secondary nameserver synchronization. Every zone must have exactly one SOA record at the zone apex. The record comprises seven fields: MNAME (primary nameserver), RNAME (admin email), Serial (version number), Refresh (sync check interval), Retry (sync failure retry interval), Expire (stale data timeout), and Minimum TTL (negative cache duration). These fields work in concert to ensure that your DNS infrastructure remains consistent and resilient. Whenever you modify a zone file, always increment the Serial Number, and use dig SOA to verify that changes have propagated correctly across all your nameservers. Mastering the SOA record is foundational to reliable DNS administration.

Frequently Asked Questions

Is the YYYYMMDDNN serial number format mandatory, or can I use a different format?

The YYYYMMDDNN format is a best-practice convention, not a requirement. The Serial Number only needs to be a larger unsigned 32-bit integer than before—you can use 1, 2, 3... if you wish. What matters is monotonic increase. However, YYYYMMDDNN is widely recommended because it tracks changes by date, preventing serial wraparound confusion, and simplifying audits.

What happens if I forget to increment the serial number after editing a zone file?

Secondary nameservers will not detect the zone update and will continue serving stale data. DNS records you've added or removed won't appear on secondaries. This is especially problematic if some DNS clients query a secondary nameserver instead of the primary. Your DNS changes will fail to propagate globally, potentially breaking services.

What are reasonable values for Refresh, Retry, and Expire?

Typical defaults are Refresh 10800 (3 hours), Retry 3600 (1 hour), Expire 604800 (1 week). For stable zones with rare changes, use longer intervals to save bandwidth. For frequently-changing zones, shorter intervals ensure faster propagation. The Retry must be less than Refresh; Expire should be much longer than both to allow time for primary recovery before secondaries retire the zone.

Why does RNAME use a dot instead of the @ symbol in email addresses?

The @ character is not permitted in DNS zone file syntax per RFC 1035. To encode an email address, DNS uses a dot (.) in place of @. Thus hostmaster.example.com. represents [email protected]. This is a DNS-specific convention and applies only to RNAME fields in SOA and some other DNS record types.