What is an SOA record, and what do its five timers actually control?

The one record every zone has exactly one of

Unlike A records or MX records, a zone can’t have zero or several SOA records — RFC 1035 requires exactly one per zone, marking, in the RFC’s own words, “the start of a zone of authority.” Query any domain’s SOA record with AdminKit’s DNS lookup tool (SOA is one of the record types it supports, alongside A, AAAA, MX, TXT, NS, CAA, PTR and CNAME) and you’ll get back two names and five numbers:

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

The two names are the primary (authoritative source of truth) name server and an email address for the zone’s administrator, written with the @ replaced by a . (so admin.example.com. means [email protected]). The five numbers are what this guide is actually about — see how to read a DNS lookup result for how SOA fits alongside the other record types AdminKit’s tool returns.

The five fields, one at a time

RFC 1035 §3.3.13 defines each field as a plain 32-bit value, measured in seconds except for serial:

• Serial — “the unsigned 32 bit version number of the original copy of the zone.” A secondary name server compares this against its own stored copy before pulling a full zone transfer; a higher serial means the zone changed. Because the field can wrap around at its maximum value, RFC 1982 defines dedicated serial number arithmetic so comparisons stay correct even across that wraparound — plain numeric comparison alone would eventually misjudge a wrapped, smaller-looking serial as older than it is.
• Refresh — “a 32 bit time interval before the zone should be refreshed.” This is how often a secondary checks the primary’s serial under normal, working conditions.
• Retry — “a 32 bit time interval that should elapse before a failed refresh should be retried.” This only kicks in once a refresh attempt has already failed to reach the primary, and is typically shorter than refresh so a secondary recovers quickly once the primary is reachable again.
• Expire — “the upper limit on the time interval that can elapse before the zone is no longer authoritative.” If a secondary can’t reach the primary for longer than expire, it stops answering queries for the zone altogether, on the assumption that its data is too stale to trust.
• Minimum — originally “the minimum TTL field that should be exported with any RR from this zone,” but RFC 2308 §4 redefined this. See the next section — this is the field most legacy documentation still describes incorrectly.

In practice, a primary doesn’t have to wait for a secondary’s own refresh timer to notice a change: DNS NOTIFY lets the primary proactively tell every secondary right after an update, which is what triggers most real-world zone transfers rather than secondaries polling on a fixed schedule — refresh is the fallback for when NOTIFY doesn’t arrive, not the primary sync mechanism on a well-configured zone.

Why “minimum” doesn’t mean “minimum TTL” anymore

RFC 1035 originally overloaded the minimum field with three purposes, including acting as a floor under every record’s TTL in the zone. RFC 2308 formally narrowed that down two decades later: “the new defined meaning of the SOA minimum field” is the negative caching TTL — how long a resolver is allowed to cache a “this name doesn’t exist” (NXDOMAIN) or “no data of this type” answer before it’s required to ask again. It no longer constrains the TTL of records that do exist in the zone; each record’s own TTL governs that, independent of what minimum says. A domain with a long minimum value and a typo in a newly-added hostname will have that typo’s “doesn’t exist” answer cached for longer than expected — a subtler version of the same caching delay covered in DNS propagation and TTL explained.

When a wrong SOA setting actually causes a problem

Most SOA misconfigurations are invisible until something goes wrong in a specific, narrow way:

• A serial that didn’t actually increment after a zone edit means secondaries never notice the change happened, and keep answering with the old records indefinitely — the single most common SOA-related support issue.
• An expire set too short relative to how often the primary has brief outages can cause a secondary to stop answering for a zone that’s actually fine, just temporarily unreachable from that one secondary.
• A minimum set very high extends how long a genuine typo or a not-yet-propagated new record’s “doesn’t exist” answer sticks around in resolver caches, which looks identical to a propagation delay from the outside — see DNS propagation and TTL explained for how to tell the two apart.

Most managed DNS providers compute and update the serial automatically and set sane defaults for the other four fields, so this mostly matters if you run your own authoritative name server, or if a zone transfer between your own primary and secondaries is behaving unexpectedly. Either way, AdminKit’s DNS lookup tool is the fastest way to see what your zone’s SOA record currently publishes, without needing shell access to the name server itself.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.