Skip to content

SOA record

Every zone has exactly one, it's created automatically when the zone is, and most people never look at it — right up until they need to explain why a DNS change took four hours to take effect for some users and four seconds for others.

SOA stands for Start of Authority, and it holds the zone's administrative metadata: who runs it, which server is its primary source, and the timers that govern how the zone propagates.

Reading one

dig +short SOA example.com

ns1.example-dns.net. admin.example.com. 2026080301 7200 3600 1209600 900

Seven fields on one line, in a fixed order:

Position Value Meaning
1 ns1.example-dns.net. MNAME — the primary nameserver, the authoritative source for the zone
2 admin.example.com. RNAME — the administrator's email address, with the @ written as a dot
3 2026080301 Serial — a version number for the zone
4 7200 Refresh — how often a secondary checks the primary for changes
5 3600 Retry — how long a secondary waits after a failed check
6 1209600 Expire — how long a secondary keeps serving data it can't refresh
7 900 Minimum — the negative-caching lifetime

That second field is worth pausing on. admin.example.com. is an email address — [email protected] — with the @ replaced by a dot, because the @ character has a different meaning in zone files. An address that already contains a dot before the @ escapes it with a backslash, which is why you occasionally see something like first\.last.example.com. and wonder what went wrong. Nothing did.

The serial is a version number with a convention

Secondary nameservers use the serial to decide whether their copy of the zone is current. They ask the primary for its SOA, compare the serial to their own, and transfer the zone only if the primary's is higher.

The near-universal convention is YYYYMMDDnn — date plus a two-digit counter for that day's changes. 2026080301 is the first change on 3 August 2026. It's readable, it sorts correctly, and it makes a stale zone obvious at a glance.

The failure it guards against is worth understanding: if you edit a zone and forget to increment the serial, secondaries never notice. The primary serves the new data, the secondaries serve the old, and which answer a user gets depends on which server their resolver happened to ask. That's the "some users see the change, some don't" symptom, and it doesn't resolve on its own — it persists until somebody bumps the serial. Managed DNS providers handle this for you; hand-edited BIND zone files do not.

Minimum controls how long a mistake lasts

The last field is the one with the most day-to-day consequence, and its name is actively misleading. Minimum hasn't meant "minimum TTL for records in this zone" since 1996. RFC 2308 redefined it as the negative caching TTL — how long resolvers may remember that a name in this zone doesn't exist.

dig api.example.com

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41022
;; AUTHORITY SECTION:
example.com.    900 IN  SOA ns1.example-dns.net. admin.example.com. 2026080301 7200 3600 1209600 900

Two things to notice. The answer is NXDOMAIN, and the SOA record appears in the authority section — that's the mechanism: the SOA is returned with the negative answer specifically so the resolver learns how long to cache it.

Which explains a support ticket that arrives regularly. Someone creates a DNS record, tests it immediately, and reports it doesn't work. What happened is that a resolver queried the name before it existed, cached the NXDOMAIN for the SOA minimum, and will keep serving that for the rest of the window regardless of the record now existing. Nothing is broken and there's nothing to fix — except the habit of testing a name before creating it.

A zone with a minimum of 86400 makes that a full day. Keeping it in the 300–900 range costs a small amount of extra query load and saves a lot of confusion.

Refresh, retry, and expire only matter with secondaries

Fields four through six govern zone transfers between a primary and its secondaries. If you run authoritative DNS yourself with a primary and two secondaries, they're live settings. If you use a managed provider, the provider runs its own replication and these numbers are decorative.

Expire is the one worth understanding even when it's decorative, because it defines a failure boundary: after this long without a successful refresh, a secondary stops answering for the zone entirely rather than serving data that may be badly out of date. Two weeks (1209600) is the common value. Setting it too short means a primary outage takes the whole domain down when the secondaries could have carried it; too long means secondaries serving weeks-old data with no indication anything is wrong.

Checking a zone's health

for ns in ns1.example-dns.net ns2.example-dns.net; do
  echo -n "$ns: "
  dig @"$ns" +short SOA example.com | awk '{print $3}'
done

ns1.example-dns.net: 2026080301
ns2.example-dns.net: 2026080215

Different serials across a zone's nameservers is a real finding: ns2 is behind. Depending on the numbers that's either a transfer in progress (check again in a minute) or a replication failure that has been quietly serving stale answers since 15 February. This one-liner belongs in a monitoring check for anyone running their own authoritative DNS — it catches a class of problem that produces no error anywhere else.

Practice

  1. Look up the SOA for three domains you use and compare their minimum values. Work out, for each, how long a mistakenly-cached NXDOMAIN would persist.
  2. Find a domain whose RNAME contains an escaped dot, and write out the actual email address it encodes.
  3. Query the SOA from every nameserver listed in a domain's NS records and compare serials.
  4. Explain, in two sentences, why editing a zone file without incrementing the serial produces inconsistent answers rather than no answers at all.

The SOA describes the zone as a whole. The next records describe specific things inside it — and the first of them runs the whole lookup backwards, mapping an address to a name instead of a name to an address.

Sources