An SOA lookup returns the Start of Authority record for a domain - the timers that control zone transfers, secondary refresh behavior, and how long a resolver may cache the fact that a name does not exist.
What is an SOA record?
Every DNS zone has exactly one Start of Authority (SOA) record, defined in RFC 1035. It identifies the primary name server for the zone, an email contact for the zone administrator, and a serial number plus four timers that secondary name servers use to stay in sync with the primary.
Unlike an A or MX record, the SOA record is not something visitors interact with directly. It exists for the machinery of DNS itself: secondaries poll it to decide when to re-transfer the zone, and resolvers use its last field to decide how long to cache a negative answer.
- Exactly one SOA record per zone, always at the zone apex
- The serial number is a version counter, not a timestamp field with defined format
- Four timers (refresh, retry, expire, minimum) control secondary sync and negative caching
The seven SOA fields
A raw SOA record is a single line with seven space-separated fields, in this fixed order: primary name server, admin email (with the @ replaced by a dot), serial, refresh, retry, expire, and minimum. A typical record looks like this:
ns1.example.com. hostmaster.example.com. 2026071401 7200 3600 1209600 3600
Reading that line field by field: ns1.example.com. is the primary (master) server for the zone; hostmaster.example.com. decodes to hostmaster@example.com; 2026071401 is the serial; and the four numbers after it are refresh, retry, expire, and minimum, all expressed in seconds.
Serial number conventions
RFC 1035 defines the serial only as a 32-bit unsigned integer compared with sequence-space arithmetic - it does not mandate a format. In practice almost every zone uses one of two conventions.
The most common is YYYYMMDDnn: a date followed by a two-digit revision counter, for example 2026071401 for the first edit made on 2026-07-14. This is popular because operators can read the last change date directly off the serial. The other convention is a plain incrementing integer that goes up by one on every edit, with no calendar meaning at all.
The only hard rule is that the serial must increase (in RFC 1035 sequence-space terms) every time the zone changes. A secondary compares the serial it holds against the one in the primary's SOA on each refresh interval; if the new value is not "greater," it assumes the zone is unchanged and skips the transfer, even if records actually changed underneath it.
Refresh, retry, expire, minimum: what each timer does
The four numeric fields after the serial are the timers secondaries use to keep the zone current. This tool reports whatever the primary is currently authoritative for; secondary servers not queried directly will not appear.
| Field | Meaning | Typical range |
|---|---|---|
| Refresh | How often a secondary checks the primary's serial to see if a transfer is needed | 1-24 hours |
| Retry | How long a secondary waits before retrying a failed refresh attempt | 10 minutes - 1 hour |
| Expire | How long a secondary keeps serving stale zone data if it cannot reach the primary at all | 1-4 weeks |
| Minimum | Negative-caching TTL - how long resolvers may cache an NXDOMAIN or no-data answer (RFC 2308) | 5 minutes - 1 hour |
The minimum field and negative caching
In the original RFC 1035, the last SOA field was documented as the default TTL for records in the zone. RFC 2308 (1998) redefined it specifically as the negative-caching TTL: the maximum time a resolver should hold onto the memory that a particular name or record type does not exist.
This matters operationally more than most administrators expect. If a domain briefly had no AAAA record and a resolver cached that absence for the full minimum value, adding an AAAA record later will not become visible to that resolver until the cached negative entry expires - no matter how low the new record's own TTL is set. A minimum field left at a legacy default of a full day means any "record doesn't exist yet" state can outlive same-day fixes.
Reading SOA lookup results
This tool queries the zone's SOA record and displays it as a single value line, in the same field order as the raw record: primary server, admin email, serial, refresh, retry, expire, minimum. There is nothing to compare it against - a domain has one authoritative SOA at a time, returned as reported by its primary name server.
If the query returns no SOA record at all, the domain either does not exist as a zone, or the query hit a server that is not authoritative for it. A working, delegated zone always has an SOA at its apex.
FAQ
Why does the SOA serial number matter if I never do zone transfers?
Even without traditional AXFR/IXFR transfers, most managed DNS providers use the same serial-comparison logic internally to propagate changes to their own edge servers. A serial that fails to increase after an edit - for example due to automation that resets it - can cause updates to silently not propagate.
What happens if the serial number overflows or wraps around?
RFC 1982 defines serial number arithmetic for exactly this case: comparisons use modular arithmetic over the 32-bit space, so a wrapped value can still be correctly recognized as "newer" up to half the number space away. In practice this only becomes relevant for zones edited extremely frequently over decades.
Can the primary name server named in the SOA record differ from the NS records for the domain?
Yes. The SOA identifies the primary (master) server used for zone maintenance, which is not always listed publicly in the zone's own NS records - some providers run a hidden primary and only publish secondary/public-facing name servers.
Why did my new record take a while to show up as unavailable, then a while to show up as available?
That is the negative-caching TTL from the SOA minimum field at work. A resolver that already cached "no such record" for that name will keep answering from cache until the cached entry's TTL, drawn from minimum, expires - independent of the TTL you set on the new record itself.
Do secondary name servers refresh on a fixed schedule regardless of the SOA refresh value?
No - refresh is the interval a secondary is supposed to honor per RFC 1035. Well-behaved secondaries also support NOTIFY (RFC 1996), which lets a primary push an immediate refresh signal after a change instead of waiting out the full refresh interval.
Is a low expire value dangerous?
It can be. Expire bounds how long a secondary will keep answering with the last known-good zone data if it completely loses contact with the primary. Setting it too low risks a secondary going non-authoritative (refusing to answer) during a primary outage that would otherwise have been invisible to users.