DNS SOA Record Explained

Every DNS zone has exactly one SOA (Start of Authority) record. It is the first record in the zone file and contains metadata about the zone itself: who is responsible for it, how often secondary servers should check for updates, and how long various timeouts should last. If A records and MX records are the instructions for finding services, the SOA record is the instructions for managing the zone.

Most domain owners never touch their SOA record directly. DNS providers generate and manage it automatically. But understanding what the SOA record contains and how it works is important when you are debugging propagation issues, setting up secondary DNS, or auditing a domain's DNS configuration. For context on where the SOA fits among all DNS record types, see DNS Record Types Explained.

What an SOA Record Looks Like

Here is a typical SOA record as returned by dig:

example.com.    3600    IN    SOA    ns1.example.com. admin.example.com. (
                                        2026041401  ; serial number
                                        7200        ; refresh
                                        3600        ; retry
                                        1209600     ; expire
                                        300         ; minimum TTL
                                    )

That is a lot of fields packed into one record. Each one has a specific purpose.

SOA Record Fields Explained

The SOA record contains seven fields. Here is what each one means and how it affects your DNS.

MNAME (Primary Nameserver)

ns1.example.com.

This is the hostname of the primary authoritative nameserver for the zone. It is the server that holds the master copy of the zone data. When secondary nameservers need to check for updates, they contact this server.

The MNAME does not have to match the NS records for the domain, though it usually does. Some DNS providers set this to an internal hostname that is not publicly listed in the NS records.

RNAME (Responsible Person)

admin.example.com.

This is the email address of the person responsible for the zone, encoded in DNS format. The @ symbol is replaced with a dot. So admin.example.com. means [email protected].

If the email address itself contains a dot before the @ (like [email protected]), the first dot is escaped with a backslash: dns\.admin.example.com.

In practice, this field is rarely used for actual contact. Many zones set it to hostmaster.example.com or admin.example.com as a convention. But it should point to a real, monitored email address in case someone needs to report DNS issues.

Serial Number

2026041401

The serial number is an integer that increments every time the zone is updated. Secondary nameservers use it to determine whether they need to fetch a fresh copy of the zone. When a secondary checks in with the primary, it compares its stored serial number against the primary's. If the primary's serial is higher, the secondary initiates a zone transfer to get the updated data.

The most common format is YYYYMMDDnn, where nn is a revision counter for that day. So 2026041401 means the first revision on April 14, 2026. The next change that day would be 2026041402.

This format is a convention, not a requirement. The serial number just needs to be an unsigned 32-bit integer that increases with each change. Some DNS providers use Unix timestamps. Others use simple incrementing integers. The format does not matter as long as it always goes up.

Refresh Interval

7200    ; 2 hours

The refresh interval tells secondary nameservers how often (in seconds) to check with the primary for zone updates. After the refresh interval expires, the secondary queries the primary's SOA record and compares serial numbers.

A shorter refresh means secondaries pick up changes faster. A longer refresh reduces the query load on the primary server. Common values range from 3600 (1 hour) to 86400 (24 hours).

For zones that change frequently, a refresh of 3600 or less is appropriate. For stable zones, 7200-14400 works well. If you use NOTIFY messages (where the primary proactively tells secondaries about changes), the refresh interval matters less because secondaries do not have to wait for it to expire.

Retry Interval

3600    ; 1 hour

If a secondary nameserver tries to contact the primary at the refresh interval and the primary does not respond, the retry interval controls how long the secondary waits before trying again. It should be shorter than the refresh interval.

A typical value is 900-3600 seconds. If the primary is temporarily unreachable (network issue, brief outage), the secondary will keep retrying at this interval until either the primary responds or the expire timer runs out.

Expire Timer

1209600    ; 14 days

The expire timer is the maximum amount of time (in seconds) a secondary nameserver will continue serving the zone data if it cannot reach the primary. Once this timer runs out without a successful refresh, the secondary stops answering queries for the zone entirely.

This is a safety mechanism. If the primary is permanently gone and the zone data is potentially stale, it is better for the secondary to stop serving it than to keep serving outdated records.

Common values range from 604800 (7 days) to 2419200 (28 days). Two weeks (1209600) is a common default. Set it long enough to survive extended outages, but short enough that you do not serve truly stale data for weeks.

Minimum TTL (Negative Cache TTL)

300    ; 5 minutes

Despite the confusing name, this field controls the TTL for negative responses. A negative response is what a resolver gets when it queries for a name that does not exist (NXDOMAIN) or a record type that does not exist for a given name (NODATA).

When a resolver gets an NXDOMAIN response, it caches that "this does not exist" answer for the duration specified in this field. This prevents repeated lookups for nonexistent names from hammering the authoritative server.

RFC 2308 clarified this field's meaning [1]. Before that RFC, the minimum TTL field was sometimes interpreted as a floor for all TTLs in the zone. Modern DNS software uses it exclusively for negative caching.

A value of 300 (5 minutes) is common. If you frequently create new subdomains and need them to be reachable quickly, a lower value (60-120 seconds) prevents stale negative cache entries from blocking access to newly created names. For more on how caching and TTL interact, see DNS Caching and TTL.

How to Check an SOA Record

Using dig

dig example.com SOA

Output:

;; ANSWER SECTION:
example.com.    3600    IN    SOA    ns1.example.com. admin.example.com. 2026041401 7200 3600 1209600 300

For a more readable format with each field labeled:

dig example.com SOA +multiline

Output:

;; ANSWER SECTION:
example.com.    3600    IN    SOA    ns1.example.com. admin.example.com. (
                                2026041401 ; serial
                                7200       ; refresh (2 hours)
                                3600       ; retry (1 hour)
                                1209600    ; expire (2 weeks)
                                300        ; minimum (5 minutes)
                                )

The +multiline flag formats the output with comments, making it much easier to read.

Using nslookup

nslookup -type=SOA example.com

Querying the Authoritative Server Directly

To see the SOA record as served by the authoritative nameserver (bypassing any caching):

dig example.com SOA @ns1.example.com

This is useful when you want to confirm a zone update has been applied to the primary but has not yet propagated to resolvers.

When SOA Records Matter

Zone Transfers (AXFR/IXFR)

The SOA record is central to how zone transfers work. When a secondary nameserver's refresh timer expires, it queries the primary for the current SOA record. If the serial number has increased, the secondary requests a zone transfer.

There are two types of zone transfers:

• AXFR (Full Zone Transfer): The secondary downloads the entire zone. Used for initial setup or when incremental data is not available.
• IXFR (Incremental Zone Transfer): The secondary downloads only the changes since its last known serial number. More efficient for large zones with small changes.

The secondary compares serial numbers to decide whether a transfer is needed at all. This is why the serial number must always increase when you make changes. If you accidentally lower it, secondaries will think they already have the latest data and will not update.

Secondary DNS and Redundancy

If you operate secondary nameservers (or use a secondary DNS provider), the SOA record controls the synchronization behavior. The refresh, retry, and expire values determine:

• How quickly secondaries pick up changes (refresh)
• How resilient the setup is to primary outages (retry + expire)
• When secondaries give up if the primary is permanently unreachable (expire)

Getting these values right is important for reliability. If the refresh is too long, DNS changes take hours to reach secondary servers. If the expire is too short, a brief primary outage causes secondaries to stop answering queries.

Debugging Propagation Issues

When DNS changes are not propagating as expected, the SOA record is one of the first things to check. Compare the SOA serial number on the primary versus the secondary:

# Check primary
dig example.com SOA @ns1.example.com +short

# Check secondary
dig example.com SOA @ns2.example.com +short

If the serial numbers do not match, the secondary has not yet picked up the latest changes. This could mean:

• The refresh interval has not elapsed yet
• Zone transfer is failing (firewall, authentication, or network issue)
• The serial number was not incremented when the zone was updated

DNSSEC Validation

SOA records play a role in DNSSEC. The negative cache TTL from the SOA is used in NSEC/NSEC3 records to define how long authenticated denial-of-existence responses can be cached. If you are running DNSSEC, incorrect SOA values can cause validation failures.

SOA Record Best Practices

Recommended Values

Always Increment the Serial Number

Every change to the zone must increment the serial number. If you are manually editing zone files, this is easy to forget. Automated DNS management tools handle this for you, but if you are working with raw zone files, build the serial increment into your workflow.

Use NOTIFY to Speed Up Propagation

Rather than waiting for the refresh interval, configure your primary nameserver to send NOTIFY messages to secondaries immediately when the zone changes. Most modern DNS software supports NOTIFY (defined in RFC 1996). This makes the refresh interval a fallback rather than the primary synchronization mechanism.

Keep Retry Shorter Than Refresh

The retry interval should always be shorter than the refresh interval. If the primary is temporarily unreachable, you want the secondary to try again relatively quickly, not wait for the full refresh cycle.

Set a Reasonable Expire

The expire value should be long enough to ride out extended outages (at least 7 days) but not so long that secondaries serve stale data for months. Two to four weeks is standard.

SOA Records at Managed DNS Providers

If you are using a managed DNS provider like Cloudflare, Route 53, or Google Cloud DNS, you typically cannot edit the SOA record directly. The provider manages the MNAME, serial number, and timing values automatically. This is usually fine. The provider's defaults are well-tested and appropriate for most use cases.

If you need specific SOA values (for example, to control refresh intervals for a secondary DNS provider), check whether your DNS provider exposes SOA editing. Some do, some do not. If they do not and you need that control, you may need to run your own authoritative nameservers or switch to a provider that allows SOA customization.

For background on how to look up any record type, including SOA, see How to Check DNS Records.

References

[1] P. Mockapetris. "Domain Names - Implementation and Specification." RFC 1035, November 1987. https://datatracker.ietf.org/doc/html/rfc1035

[2] M. Andrews. "Negative Caching of DNS Queries (DNS NCACHE)." RFC 2308, March 1998. https://datatracker.ietf.org/doc/html/rfc2308

[3] P. Vixie. "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)." RFC 1996, August 1996. https://datatracker.ietf.org/doc/html/rfc1996

The SOA record is the administrative backbone of every DNS zone. You may never need to edit it directly, but knowing how to read it is essential for debugging propagation, managing secondary DNS, and understanding how your zone stays synchronized.