SOA Records Explained: The Record That Describes Your Zone

Every DNS zone has exactly one SOA record, and unlike A records or MX records, you'll almost never add or edit one directly. Most DNS providers generate it automatically and update it behind the scenes. That's exactly why it's worth understanding: when something about your zone behaves strangely and every other record looks correct, the SOA record is often where the actual explanation lives.

What an SOA record is

SOA stands for Start of Authority. It's metadata about the zone itself, not about any individual hostname. Where an A record answers "where does this name point," the SOA record answers questions like "who's authoritative here, how fresh is this data, and how should secondary nameservers treat it."

A typical SOA record looks like this:

example.com.  SOA  ns1.example.com. admin.example.com. (
                    2026070901  ; serial
                    7200        ; refresh
                    3600        ; retry
                    1209600     ; expire
                    300 )       ; minimum

The fields, in order

Primary nameserver (ns1.example.com.) — the nameserver considered the master source of the zone's data. In modern managed DNS, this is often more of a formality than a functional distinction, since most providers replicate changes across an anycast network rather than a true single primary, but the field is still required.

Responsible party (admin.example.com.) — an email address for whoever administers the zone, encoded as a hostname instead of using an @. Read admin.example.com. as [email protected]. The substitution exists because @ is a reserved character in zone file syntax. This field is rarely used for anything in practice, and providers often set it to a generic address.

Serial (2026070901) — a number that increments every time the zone changes. This is the field secondary nameservers actually watch. A common convention encodes the date plus a two-digit revision (YYYYMMDDnn), but the format doesn't matter to DNS itself; only that the number increases with each change.

Refresh (7200) — how often, in seconds, a secondary nameserver should check the primary for updates by comparing serial numbers.

Retry (3600) — how long a secondary should wait before retrying if a refresh check fails to reach the primary.

Expire (1209600) — how long a secondary can keep serving a zone it hasn't been able to refresh from the primary before it stops answering for that zone entirely, on the assumption the data is too stale to trust.

Minimum (300) — historically the default TTL for records in the zone that don't specify their own. Its meaning was later redefined by RFC 2308 to instead control negative caching: how long resolvers cache the fact that a record doesn't exist (an NXDOMAIN response). A low minimum means a typo'd or not-yet-created hostname stops returning NXDOMAIN quickly once it's fixed. A high one means that negative answer sticks around longer, delaying the fix from being visible.

Why the serial number is the field that matters most

Everything about how secondary nameservers stay in sync depends on the serial number changing when the zone changes. When a secondary's refresh interval elapses, it queries the primary's SOA record and compares serial numbers. A higher serial on the primary means "pull the updated zone." An unchanged serial means "nothing to do."

If a zone is edited but the serial isn't incremented, which mostly happens with hand-maintained zone files rather than provider dashboards that increment it automatically, secondaries have no signal that anything changed. They'll keep serving the old data until the serial finally moves, at which point all the accumulated changes propagate at once. This is a specific, easy-to-miss failure mode: the primary is correct, the change was saved successfully, and yet the outside world keeps seeing stale answers because nothing told the secondaries to look again.

Almost every managed DNS provider handles serial incrementing automatically now, which is part of why this used to be a much more common problem than it is today. It mainly resurfaces with self-managed BIND zone files edited by hand.

What a stale SOA actually breaks

If you're troubleshooting a domain where some records seem outdated in a way that doesn't match your TTLs, checking the SOA serial across your nameservers is a useful diagnostic step:

dig @ns1.example.com example.com SOA
dig @ns2.example.com example.com SOA

If the serial numbers differ between your nameservers, one of them hasn't synced the latest zone data. That's a more specific and more useful signal than "my DNS seems wrong," because it points directly at a zone transfer problem rather than an ordinary caching delay. This is a different failure than the propagation delay described in Why DNS Propagation Takes So Long: propagation is resolvers waiting out a TTL on correct data; a serial mismatch between your own nameservers means the zone data itself hasn't finished replicating.

How DNS monitoring fits in

The SOA record isn't usually something you monitor for its own sake the way you would an A or MX record, since it changes on every edit by design. What's worth watching is the primary nameserver field and the overall zone consistency: if it starts pointing somewhere unexpected, or one of your nameservers is serving a persistently different serial than the others, that's a sign something's wrong with how your zone is being replicated.

OneDollarDNS monitors your zone's records directly against your authoritative nameservers, which is what makes a nameserver serving stale or inconsistent data visible in the first place, rather than only checking a single cached view of your domain.