SOA Record Explained

The Start of Authority record controls zone ownership and secondary refresh behavior

Every normal authoritative DNS zone has exactly one SOA record at the zone apex. In BIND zone files it is usually the first resource record after directives such as $TTL. If the SOA is missing or malformed, named-checkzone will reject the zone.

Example SOA Record

@   IN  SOA  ns1.example.test. hostmaster.example.test. (
                2026051501  ; serial
                7200        ; refresh
                3600        ; retry
                1209600     ; expire
                3600        ; negative cache ttl
)

SOA Fields

Field	Purpose	Example
Primary nameserver	The primary source for the zone data, written as a domain name.	`ns1.example.test.`
Responsible mailbox	A mailbox written as a DNS name, not as a literal email address.	`hostmaster.example.test.`
Serial	A version number that secondary servers use to decide whether to transfer a new copy.	`2026051501`
Refresh	How often secondaries check the primary for a new serial.	`7200`
Retry	How long a secondary waits before retrying a failed refresh.	`3600`
Expire	How long a secondary may serve stale data if it cannot refresh.	`1209600`
Negative cache TTL	Used in negative responses such as NXDOMAIN, together with the SOA TTL behavior of the authoritative server.	`3600`

Responsible Mailbox Format

The second SOA name represents an email address. The first unescaped dot becomes @, so hostmaster.example.test. represents [email protected]. If the local part itself contains a dot, escape it: first\.last.example.test. represents [email protected].

Serial Number Strategy

The serial must increase whenever the zone changes. A common convention is YYYYMMDDnn, where nn is the change number for that date. For example, 2026051501 is the first change on 2026-05-15 and 2026051502 is the second.

BIND compares SOA serials using DNS serial number arithmetic, not simple unlimited integers. Avoid huge jumps unless you understand RFC 1982 behavior, and keep the process simple enough that operators will not accidentally publish an older serial.

Choosing Timing Values

Refresh and retry values mostly affect secondary authoritative servers. Shorter values can make secondaries notice changes sooner, but they also increase polling. For many small zones, values around 1 to 4 hours for refresh, 15 minutes to 1 hour for retry, and 1 to 2 weeks for expire are common starting points. Match the values to your operational needs and the behavior expected by your DNS provider.

Checking an SOA edit? Validate the whole zone before publishing it.

Open the Validator