What is an SOA record? DNS Start of Authority, explained

Quick answer

An SOA (Start of Authority) record holds the administrative parameters for a DNS zone: who the primary nameserver is, who administers the zone, a version serial, and the timers that control how secondary nameservers and resolvers cache the zone (RFC 1035 §3.3.13). Every zone has exactly one SOA record, and it lives at the zone apex. It is created automatically when you delegate a domain, so you rarely write one by hand, but reading it tells you why changes propagate the way they do.

The seven SOA fields, in order

An SOA record's RDATA is seven fields in a fixed order (RFC 1035 §3.3.13):

• MNAME — the domain name of the primary (master) nameserver, the original source of data for the zone.
• RNAME — the mailbox of the person responsible for the zone, written as a domain name (see the format note below).
• SERIAL — an unsigned 32-bit version number for the zone. Zone transfers preserve this value.
• REFRESH — how long a secondary waits before checking the primary for a new serial.
• RETRY — how long a secondary waits before retrying a REFRESH that failed.
• EXPIRE — the upper limit on how long a secondary keeps answering for the zone when it cannot reach the primary.
• MINIMUM — the TTL used for negative (no-such-name / no-such-record) responses. This is not the zone's default record TTL; see below.

A typical SOA in BIND zone-file format:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026070501  ; SERIAL  (YYYYMMDDnn)
                             7200        ; REFRESH (2h)
                             3600        ; RETRY   (1h)
                             1209600     ; EXPIRE  (14d)
                             3600 )      ; MINIMUM (negative-cache TTL, 1h)

The MINIMUM field is the negative-cache TTL, not a record TTL

This is the single most misread field in DNS. In the original RFC 1035 text, MINIMUM was described as the minimum TTL exported with records from the zone. RFC 2308 §4 deprecated that meaning and redefined MINIMUM as the TTL to be used for negative responses. In other words, when a resolver asks for a name that does not exist (NXDOMAIN) or a record type that does not exist (NODATA), the authoritative server returns the SOA in the authority section, and the resolver caches that negative answer.

The exact negative TTL is the smaller of SOA.MINIMUM and the SOA record's own TTL (RFC 2308 §5). So MINIMUM does not set the default TTL for your A, MX, or TXT records. Each record carries its own TTL. If you set MINIMUM to a large value expecting it to speed up positive lookups, you instead make wrong answers stick: a mistyped or not-yet-published name stays cached as nonexistent for that whole interval. A value in the range of 300 to 3600 seconds is a common, safe choice.

The RNAME format: an email address with a dot for the @

RNAME is the zone administrator's mailbox, but DNS stores it as a domain name, so the @ is replaced by a dot. The first unescaped dot marks the boundary between the local part and the domain. So hostmaster.example.com means hostmaster@example.com, and admin.relaymetry.com means admin@relaymetry.com.

If the local part itself contains a dot, escape it with a backslash, following the master-file character rules in RFC 1035 §5.1. So Action\.domains.example.com decodes to Action.domains@example.com. Getting this wrong sends zone-related mail to the wrong address, which matters when a registrar or monitoring system tries to reach the responsible party.

Why your zone edits aren't propagating

If you edited your zone but secondaries are still serving old data, the usual cause is the SERIAL. Secondary nameservers detect changes by comparing the serial they hold against the primary's serial during a REFRESH poll. If the new serial is not higher than the old one, the secondary concludes nothing changed and skips the transfer, so your edit never leaves the primary.

The fix is to increment SERIAL on every zone change. Many operators use the YYYYMMDDnn convention (four-digit year, month, day, then a two-digit counter for edits made the same day), which is human-readable and naturally increasing. Any strictly increasing integer works, but note that serials use RFC 1982 sequence-space arithmetic, so a serial can wrap. Keep serials monotonically increasing and never reset them downward. Most managed DNS providers and hidden-primary setups bump the serial for you on save, but if you run your own primary you own this step.

How REFRESH, RETRY, and EXPIRE govern secondaries

These three timers describe the relationship between a primary and its secondary (slave) nameservers when the zone is served by more than one authority.

• REFRESH sets the polling interval. Every REFRESH seconds, a secondary queries the primary's SOA and compares serials. Modern setups also use NOTIFY for near-instant updates, but REFRESH remains the fallback poll.
• RETRY is used when a REFRESH attempt fails, for example because the primary is unreachable. The secondary waits RETRY seconds, then tries again. RETRY is normally shorter than REFRESH.
• EXPIRE is the safety limit. If a secondary cannot reach the primary for EXPIRE seconds, it stops answering for the zone entirely and returns SERVFAIL, on the assumption that its copy is now too stale to trust. EXPIRE should be comfortably longer than REFRESH so a brief primary outage does not take the zone offline.

The SOA is a companion to the zone's NS record set: the NS records name the authoritative servers, and the SOA's timers tell those servers how to stay in sync. To see one, query it directly. On any command line, dig SOA example.com +multiline prints the seven fields with labels; nslookup -type=SOA example.com works on Windows. For the wider map of what each record type does, see DNS record types and the A record page.

Related guides

• NS record: how DNS delegation works
• A record: what it is and how to read one
• DNS record types explained