The SOA Record Explained: Serial, Refresh, Retry, Expire and Negative TTL

Every DNS zone has exactly one Start of Authority record, and it sits quietly at the root of the zone governing things most people never think about until something breaks: how secondary nameservers stay in sync with the primary, and how long resolvers remember that a name does not exist. The SOA record packs seven fields into one line: the primary nameserver, the admin contact, a serial number, and four timers. Get the serial wrong and zone transfers stall. Set the last timer too high and a newly added record seems to take hours to appear. This guide breaks down each field, shows a correct example, and explains the two failure modes that trip people up most.

What the SOA record is for

The SOA record answers two operational questions. First, in a primary-secondary setup, how and when do the secondary servers pull updates from the primary? Second, when a resolver asks for a name that does not exist, how long should it cache that "no such name" answer before asking again? Those jobs are handled by the serial number, the refresh, retry, and expire timers, and the minimum field. Here is a complete record:

example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
    2026101201 ; serial
    7200       ; refresh (2 hours)
    3600       ; retry   (1 hour)
    1209600    ; expire  (2 weeks)
    3600 )     ; minimum (negative-cache TTL, 1 hour)

Querying it live looks like this:

dig +short SOA example.com
ns1.example.com. hostmaster.example.com. 2026101201 7200 3600 1209600 3600

The two name fields: MNAME and RNAME

MNAME: the primary nameserver

MNAME is the hostname of the primary (master) nameserver that holds the original, authoritative copy of the zone. Secondary servers use this value to know where to pull zone transfers from, and dynamic DNS updates are directed here.

RNAME: the responsible person

RNAME is the administrative contact's email address written in DNS format, where the first dot stands in for the @ sign. So hostmaster.example.com. means hostmaster@example.com. If the local part of the email itself contains a dot, it is escaped with a backslash, but using a simple mailbox like hostmaster avoids that complication entirely.

The serial number and the date convention

The serial is a version number for the zone. Secondary servers compare the serial they hold against the primary's; if the primary's serial is higher, they pull a fresh copy, and if it is the same or lower, they do nothing. The rule is simple and unforgiving: you must increment the serial every single time you edit the zone, or the change will never propagate to secondaries.

The widely used convention is YYYYMMDDnn: a four-digit year, two-digit month, two-digit day, and a two-digit counter for edits made that day. So 2026101201 is the first edit on 2026-10-12, and the second edit the same day becomes 2026101202. The format is human-readable and keeps serials monotonically increasing as long as you remember to bump the counter.

The three sync timers: refresh, retry, expire

These three values, all in seconds, control how secondary servers behave when keeping their copy of the zone current. They only matter when you run secondaries; if your provider handles replication for you, it may ignore them, but they are still part of the record.

Retry should always be shorter than refresh, and expire should be comfortably larger than both, long enough to ride out an extended primary outage without the secondaries going dark. A two-week expire is a common, safe choice.

The minimum field: negative-cache TTL

The minimum field is the one that surprises people. Despite the name, since RFC 2308 it does not set a default TTL for the zone's records. Instead it defines the negative-cache TTL: how long resolvers cache a negative answer, meaning an NXDOMAIN response that says a name does not exist. More precisely, RFC 2308 says the negative answer is cached for the smaller of the SOA record's own TTL and its minimum field.

Sensible values run from 300 to 3600 seconds. Lower values mean a newly created record becomes visible faster after someone looked it up while it was still missing; higher values reduce repeated queries for names that genuinely do not exist.

Two failure modes to watch for

A stale serial stops zone transfers

If you edit the zone but forget to increment the serial, secondary servers compare serials, see no increase, and conclude nothing changed. Your edit lives on the primary but never reaches the secondaries, so resolvers that happen to query a secondary keep serving the old data. The symptom is maddening: the change works from one nameserver and not another. Always bump the serial, and verify both servers agree:

dig +short SOA example.com @ns1.example.com
dig +short SOA example.com @ns2.example.com
# the serial in both answers must match after propagation

A high negative TTL delays a newly added record

Suppose someone queries new.example.com before you create it. The resolver gets an NXDOMAIN and caches that "does not exist" answer for the negative-cache TTL. You then add the record, but that resolver keeps returning "not found" until the negative cache expires. If your minimum field is set to 86400, that is a full day of the new record appearing broken to anyone whose resolver cached the miss. Keeping the negative TTL in the 300 to 3600 range avoids most of this pain.

Sensible defaults

Most managed DNS providers set reasonable SOA values for you and increment the serial automatically on every edit, so you rarely touch these by hand. But when you audit a zone, run your own secondaries, or chase a propagation mystery, reading the SOA correctly is what tells you whether the problem is a forgotten serial bump or an oversized negative cache.

To see the live SOA and confirm every nameserver is serving the same serial, run your domain through the Valla DNS lookup and propagation checker, and pair this with our other guides in the Valla DNS learning hub on TTL strategy, NS delegation, and record types to round out your zone knowledge.