What Is a DNS SOA Record and Why It Matters for Your Domain

What Is an SOA Record?

The SOA (Start of Authority) record is the first record in every DNS zone and the only one that must exist exactly once. It names the primary nameserver for the zone, the administrator's contact address, and a set of timers that tell secondary nameservers how to keep their copy of the zone in sync.

Unlike an A or MX record, the SOA is not there to answer user queries. It is metadata about the zone itself: who is authoritative for it, which version of the zone this is, and how long other servers may trust or cache that version. If the SOA is wrong, the zone can still resolve today — but it will fail to update, fail to expire, or cache errors for far too long.

You can see the SOA record of any domain with dig:

dig SOA example.com +short

A typical answer looks like this:

ns1.example.com. hostmaster.example.com. 2026082601 3600 900 1209600 300

The seven values are the primary nameserver, the responsible mailbox, and five numbers — the serial and four timers — explained below.

The Seven SOA Fields Explained

Every SOA record carries the same seven fields, in this order:

MNAME — the primary nameserver for the zone. Secondaries send their refresh queries and expect NOTIFY messages from this host. It should be a hostname that resolves, not an IP address.

RNAME — the mailbox of the person responsible for the zone, written with a dot instead of the @: hostmaster.example.com means [email protected]. If the local part itself contains a dot, it is escaped with a backslash.

Serial — the version number of the zone. Secondaries compare it with their own copy to decide whether the zone has changed. It is the single most important field for keeping secondary nameservers up to date.

Refresh — how often, in seconds, a secondary asks the primary for the current serial. 3600 (one hour) is a common value. With NOTIFY in place this timer is only a safety net.

Retry — how long a secondary waits before asking again after a refresh attempt fails. It should be shorter than refresh; 900 (15 minutes) is typical.

Expire — how long a secondary keeps serving the zone after it last managed to reach the primary. When this timer runs out, the secondary stops answering for the zone entirely. 1209600 (two weeks) is the usual value.

Minimum — historically the default TTL for records; since RFC 2308 it defines the negative caching TTL: how long resolvers may cache the fact that a name does not exist (NXDOMAIN). The effective negative TTL is the lesser of this field and the TTL of the SOA record itself. 300 to 3600 is a sensible range.

How Secondary Nameservers Use the SOA

The SOA record is the contract between your primary nameserver and every secondary that serves your zone. A secondary follows this cycle:

1. Every refresh seconds, it queries the primary for the SOA record. 2. It compares the serial in the answer with the serial of its own copy. 3. If the primary's serial is higher, it requests a zone transfer (AXFR or IXFR) and installs the new copy. 4. If the query fails, it tries again after retry seconds. 5. If it cannot reach the primary for expire seconds, it discards the zone and returns SERVFAIL until the primary is back.

Most primaries also send a NOTIFY message the moment the zone changes, so the secondary checks the serial immediately instead of waiting for the refresh timer. The timers still matter: NOTIFY can be lost, blocked by a firewall, or simply not configured, and then refresh and retry are the only thing keeping the copies in sync.

This is why a hosted secondary DNS service can keep your domain online while the primary is down: it already holds a full, current copy of the zone and keeps answering for it until expire runs out. See DNS Redundancy for the bigger picture and Understanding AXFR Zone Transfers for how the transfer itself works.

The Serial Number: Formats and Classic Mistakes

The serial is an unsigned 32-bit integer, and the only rule the protocol enforces is that a newer zone must carry a larger serial than the one before it. Secondaries do not look at dates or file timestamps — only at this number.

Date-based serials are the most common convention: YYYYMMDDnn, for example 2026082601 for the first change on 26 August 2026. The last two digits allow up to 100 edits per day, and the number stays human-readable in dig output.

Unix-timestamp serials are used by many managed DNS providers and by BIND when configured with serial-format unixtime. They increase automatically and never collide.

Plain counters (1, 2, 3, …) are perfectly valid too. The format is a convention, not a requirement.

The mistakes that actually break zones:

- Forgetting to increment the serial. You edit the zone file, reload the primary, and it answers with the new data — but every secondary still sees the old serial, decides nothing changed, and keeps serving stale records indefinitely. This is the single most common cause of "the change works on ns1 but not on ns2".

- Going backwards. Switching from a large timestamp serial to a small date-based one, or restoring an old zone file, leaves the secondary with a higher serial than the primary. It will never transfer again until the primary's serial overtakes it. Serial arithmetic (RFC 1982) offers a way out: add 2^31 − 1 (2147483647) to the serial, let every secondary pick it up, then set the value you actually want — the second step is again seen as an increase.

- Editing the serial on a secondary. Secondaries must never be edited by hand; the next transfer overwrites the copy, and the manual change disappears.

Choosing Refresh, Retry, Expire and Minimum Values

RFC 1912 gives the classic guidance, and it still holds. Reasonable defaults for a zone that has NOTIFY configured:

Refresh — 1 hour (3600) Retry — 15 minutes (900) Expire — 2 weeks (1209600) Minimum — 5 minutes to 1 hour (300 – 3600)

The two rules that matter more than the exact numbers:

Retry must be shorter than refresh, and ideally a small fraction of it — otherwise a failed refresh simply waits for the next scheduled one and the retry timer does nothing.

Expire must be longer than the longest outage you can imagine on the primary. If the primary goes down on Friday evening and nobody notices until Monday, an expire of 86400 (one day) means every secondary stopped answering on Saturday — and the whole point of having secondaries is lost. Two weeks is the common choice and the floor for a production zone; RFC 1912 suggests two to four weeks.

For minimum (negative caching), shorter values let a newly created record become visible faster after it was queried while it did not exist; longer values reduce load from repeated lookups of names that will never exist. Do not set it above a few hours — a typo in a hostname would otherwise be cached as non-existent for a whole day.

Diagnosing a Stale Secondary With dig

When a DNS change is visible on one nameserver but not another, the SOA serial tells you where the problem is. Ask each authoritative server directly:

dig @ns1.example.com example.com SOA +short
dig @ns2.example.com example.com SOA +short

Three outcomes:

Same serial on both — the zone is in sync. If a record still looks wrong, the problem is caching at the resolver, not replication; wait for the record's TTL or query the authoritative server directly.

Lower serial on the secondary — the secondary knows the zone but has not picked up the latest version. Check that the serial on the primary was actually incremented, that the primary allows transfers from the secondary's IP (allow-transfer / allow-axfr-ips), that TCP port 53 is open between them, and whether the primary sends NOTIFY at all.

SERVFAIL or REFUSED from the secondary — the zone either never transferred or has expired. Look at the secondary's log for the last successful transfer; if it is older than the expire value, the secondary has correctly dropped the zone and needs the primary back before it can reload it.

A secondary that is supposed to be in sync but is not is a silent failure: it keeps answering, just with old data. Monitoring the serial on every nameserver — not only reachability — is the only way to catch it before users do.

SOA Record Example for a Typical Zone

A complete SOA record in zone-file syntax, with the timers from the table above:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
        2026082601  ; serial  (YYYYMMDDnn)
        3600        ; refresh (1 hour)
        900         ; retry   (15 minutes)
        1209600     ; expire  (2 weeks)
        300 )       ; minimum (negative caching TTL, 5 minutes)

The 3600 before IN is the TTL of the SOA record itself — how long resolvers may cache it. It also caps the negative caching TTL: with 3600 here and a minimum of 300, resolvers cache NXDOMAIN answers for 300 seconds, the lesser of the two.

If you use a hosting panel or a DNS provider's web interface, the SOA is usually generated for you, and the serial is incremented automatically on every save. It is still worth checking the timer values once: some panels ship an expire of one day, which quietly defeats any secondary you add later.

Related Guides

The SOA record is the mechanism; these guides cover what it is for:

- DNS Redundancy: Why It Matters and How to Achieve It - Understanding AXFR Zone Transfers - How to Set Up a Secondary DNS Server