SOA, the Start of Authority record, is the DNS record that marks the beginning of a zone and holds its administrative and timing parameters. Every DNS zone must contain exactly one SOA record at its apex, and it tells other servers which nameserver is the primary source of the zone, who is responsible for it, which version of the zone is current and how secondary servers and resolvers should time their behavior.
Among DNS records, the SOA is unusual because users never look it up directly when browsing. It matters to zone transfers, secondary nameservers and negative caching, and errors in it cause stale data, failed synchronization or answers that stay missing longer than expected.
Structure of the SOA record
The SOA record has seven data fields defined in the original DNS specification, RFC 1035, and its own TTL like any other record. In zone file notation it looks like example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. 2026111001 7200 3600 1209600 300.
| Field | Meaning | Example value |
|---|---|---|
| MNAME | Primary nameserver for the zone | ns1.example.com. |
| RNAME | Mailbox of the responsible person, with the first dot replacing the @ sign | hostmaster.example.com. |
| SERIAL | Version number of the zone | 2026111001 |
| REFRESH | How often secondaries check for changes | 7,200 s |
| RETRY | Wait before retrying a failed refresh | 3,600 s |
| EXPIRE | When secondaries stop answering without contact | 1,209,600 s |
| MINIMUM | Used for the negative caching TTL | 300 s |
The RNAME encoding often confuses administrators: hostmaster.example.com. means the address hostmaster at example.com. A dot inside the local part must be escaped with a backslash, otherwise it is read as the separator.
How the SOA record controls zone synchronization
In classic primary and secondary setups, the SOA serial number is the signal for change. A secondary nameserver periodically queries the primary’s SOA record after each REFRESH interval. If the serial is higher than its own copy, it requests a zone transfer, either a full transfer (AXFR) or an incremental one (IXFR).
Modern servers do not wait for the refresh timer alone. The primary sends a DNS NOTIFY message to its secondaries as soon as the zone changes, and each secondary immediately checks the SOA serial. The timers remain a safety net for lost notifications.
If a secondary cannot reach the primary, it retries after each RETRY interval. When the EXPIRE time passes without a successful refresh, the secondary stops answering for the zone, on the principle that no answer is safer than badly outdated data.
Serial numbers are compared with serial number arithmetic defined in RFC 1982, so they can wrap around within the 32-bit space. The common YYYYMMDDnn convention, a date followed by a two-digit change counter, allows up to 100 changes per day and makes the age of a zone readable at a glance.
Recommended values for SOA timers
No single set of SOA values is correct for every zone. The right numbers depend on how often the zone changes, how reliable the links between servers are and whether NOTIFY is in use. The ranges below reflect widely used operational practice.
| Field | Common range | Too low causes | Too high causes |
|---|---|---|---|
| REFRESH | 1,200 to 86,400 s | Unnecessary SOA queries | Slow updates if NOTIFY fails |
| RETRY | 600 to 7,200 s | Query bursts during outages | Long recovery after failures |
| EXPIRE | 604,800 to 2,419,200 s | Zone vanishes during short outages | Stale data served for weeks |
| MINIMUM | 300 to 3,600 s | More repeated negative queries | New names appear missing for long |
RETRY should be shorter than REFRESH, and EXPIRE should be much longer than both, typically one to four weeks, so that a weekend outage of the primary never takes the zone offline.
The SOA record and negative caching
The meaning of the MINIMUM field changed over time. Originally it set a minimum TTL for records in the zone; since RFC 2308 it defines the negative caching TTL. When a resolver receives an answer that a name or record type does not exist, the authoritative server includes the SOA record, and the resolver caches the negative result for the lower of the SOA TTL and the MINIMUM value.
This has a direct operational consequence. If a client looks up a name before it is created, the missing answer stays cached for the negative TTL. A zone with a MINIMUM of 86,400 seconds can make a newly added subdomain appear absent for up to a day to anyone who queried it too early.
SOA compared with other DNS records
The SOA record is often confused with the NS record, because both describe nameservers. They answer different questions.
| Record | Purpose | Number per zone |
|---|---|---|
| SOA | Zone authority, version and timers | Exactly one at the apex |
| NS | Lists all authoritative nameservers | Two or more recommended |
| DS | Links a signed child zone to its parent | In the parent zone |
| DNSKEY | Publishes the zone’s signing keys | One or more at the apex |
The MNAME in the SOA names only the primary source of edits; resolvers do not query it preferentially. Some providers place any of their nameservers in MNAME, especially in anycast and hidden primary designs, where the true primary is not publicly reachable.
Common SOA mistakes
- Forgetting to increment the serial after editing a zone file, so secondaries keep serving old data.
- Decreasing the serial, which secondaries treat as an older version and ignore.
- Writing an @ sign in RNAME, which produces an invalid or misleading contact address.
- Setting EXPIRE shorter than REFRESH, which can make secondaries drop the zone during normal operation.
- Using a very high MINIMUM, which keeps newly created names invisible for hours.
Managed DNS platforms usually increment the serial automatically, but administrators of self-hosted servers must manage it carefully, and monitoring should compare the serial on every authoritative server to detect synchronization failures.
In simple terms
Every domain’s DNS settings are kept in a collection called a zone. The SOA record is the cover page of that collection. It says who manages it, which server holds the master copy and which edition number the collection currently has.
Backup servers read the cover page regularly. When they see a higher edition number, they fetch the new version. The cover page also says how long others should remember that a name does not exist. Most people never see it, but DNS relies on it to keep every copy in agreement.
A practical example
A university runs its own primary nameserver and two secondary servers at other campuses. An administrator adds a record for a new research portal but forgets to raise the serial from 2026110901 to 2026111001. The primary answers correctly, yet both secondaries keep their older copy, so about two thirds of lookups fail to find the portal.
Monitoring that compares SOA serials across all three servers raises an alert within minutes. The administrator increments the serial and reloads the zone; the primary sends NOTIFY, both secondaries perform an incremental transfer and report the new serial. The team also lowers the MINIMUM from 86,400 to 300 seconds, so that the failed lookups cached as missing expire quickly and the portal becomes reachable everywhere within five minutes.