Skip to content
ProbeDNS

SOA Record Lookup

The SOA (Start of Authority) record sits at the apex of every DNS zone and defines it: which server is primary, who administers it, the serial number secondaries use to detect changes, and the timers that govern zone transfers and negative caching. Exactly one SOA exists per zone.

Every field, and what it actually controls

dig +noall +answer wikipedia.org SOA
wikipedia.org.	3600 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2026060420 43200 7200 1209600 3600
A real SOA record. The seven values after the two names are the serial and the timers.
FieldValue aboveWhat it does
MNAME (primary)ns0.wikimedia.org.The primary nameserver for the zone. Where dynamic updates and NOTIFY messages go. Not necessarily the server answering you.
RNAME (hostmaster)hostmaster.wikimedia.org.Administrator email with the @ replaced by a dot: [email protected].
Serial2026060420Version number of the zone. Secondaries transfer a new copy only when this increases.
Refresh43200How often a secondary checks the primary for a higher serial (12 hours here).
Retry7200How long a secondary waits before retrying after a failed refresh (2 hours).
Expire1209600How long a secondary keeps serving the zone when the primary is unreachable (14 days). After this, it stops answering entirely.
Minimum3600Negative caching TTL — how long resolvers cache an NXDOMAIN or empty answer for this zone (RFC 2308).

The Minimum field is the one that bites people, because its meaning changed. It originally set a default TTL for records in the zone; RFC 2308 redefined it as the negative-caching TTL. It now controls how long the *absence* of a record is remembered.

Check a record before you create it and the negative answer is cached for the SOA Minimum period — often an hour, sometimes a day. The record exists but you still cannot see it, and no amount of local cache flushing helps because the cache holding it is your ISP's. This is the single most common "my DNS change is not working" complaint.

Reading the serial number

Most operators use the YYYYMMDDnn convention: 2026060420 is the twentieth revision made on 4 June 2026. It is a convention, not a rule — some providers use Unix timestamps, some use plain counters, and hosted DNS platforms often bump it in ways you cannot predict.

Read the full explanation of soa record lookup results ↓

What matters operationally is that the serial only ever increases (in serial-number arithmetic, RFC 1982). Two practical uses follow. First, comparing the serial across a zone's nameservers tells you instantly whether they are in sync — a secondary lagging behind means a zone transfer is failing. Second, if you make a change and the serial does not move, your provider has not published it.

What SOA tells you about a zone's health

  • No SOA at the name you queried means it is not a zone apex. www.example.com has no SOA; example.com does. Query the registrable domain.
  • A different serial on different nameservers means replication is broken or in progress. Query each server from the NS lookup directly and compare.
  • An RNAME pointing at a mailbox nobody reads is a real risk: registries, certificate authorities, and abuse desks use it. Note that the first dot is the @ — hostmaster.example.com means [email protected], but first.last.example.com means [email protected].
  • A very large Minimum (86400) means mistakes are expensive: a mistyped record checked once will be remembered as nonexistent for a day. 300–3600 is a saner range for zones under active change.
  • Expire shorter than a few days risks a secondary going silent during a long primary outage — exactly when you need it most.

Common failures and fixes

  1. "I added the record but it is still not found." You almost certainly queried it before adding it and got a negative answer cached for the Minimum period. Confirm against the authoritative server with dig @ns1.provider.com name TXT — if it answers there, you are simply waiting out negative cache.
  2. Secondaries serving stale data. The serial did not increase, or the zone transfer is blocked. Check that the primary permits AXFR/IXFR from the secondary addresses and that NOTIFY reaches them.
  3. Zone vanished from a secondary. The Expire timer elapsed while the primary was unreachable. Restore the primary; the secondary reloads on the next successful refresh.
  4. SOA MNAME points at a decommissioned server. Harmless for ordinary lookups but breaks dynamic DNS updates and NOTIFY-driven replication. Update it during your next zone edit.
  5. Serial went backwards after a provider migration. Secondaries will refuse to transfer the "older" zone. Set the serial higher than the largest previously published value, or use the RFC 1982 wrap-around procedure.

Comparing SOA across every nameserver

This one-liner is the fastest zone-consistency check there is. It asks every authoritative server for the zone's SOA and prints the serials side by side:

# Serial from every authoritative nameserver
for ns in $(dig +short wikipedia.org NS); do
  echo -n "$ns: "
  dig +short @"$ns" wikipedia.org SOA | awk '{print $3}'
done

# The full SOA with all timers
dig +noall +answer wikipedia.org SOA

# Just the negative-cache TTL (last field)
dig +short wikipedia.org SOA | awk '{print $7}'
Identical serials across every server means the zone is fully replicated.

For a broader view of whether a change has reached the wider internet rather than just the authoritative servers, use the DNS propagation checker or compare four major public resolvers with DNS Compare.

Frequently asked questions

What is the SOA record used for?
It marks the start of a DNS zone and carries the zone's administrative metadata: the primary nameserver, the hostmaster address, the serial number secondaries use to detect changes, the refresh/retry/expire timers that drive zone transfers, and the negative-caching TTL. Every zone has exactly one, at its apex.
Why does my subdomain have no SOA record?
Because it is not a separate zone. A subdomain only has its own SOA if it has been delegated with NS records to its own nameservers. Otherwise it is just a name inside the parent zone, and the parent's SOA applies. An empty result here is the normal answer for www.
What does the SOA minimum field control?
Negative caching, per RFC 2308: how long resolvers remember that a name or record type does not exist. It no longer sets a default TTL for records, despite the name. A high value means typos and premature checks are remembered for a long time.
How do I know if my zone transferred to the secondary?
Query each nameserver for the SOA and compare serial numbers. Matching serials mean the secondary has the same zone version as the primary. A lower serial on the secondary means the transfer failed or has not run yet — check ACLs on the primary and whether NOTIFY is reaching the secondary.
Does the serial number have to follow the date format?
No. Any unsigned 32-bit number works, as long as it increases under RFC 1982 serial arithmetic. YYYYMMDDnn is a convention because it is human-readable and naturally increasing; Unix timestamps and simple counters are equally valid. Hosted providers usually manage it for you.
What happens when the expire timer runs out?
A secondary that has not reached the primary for longer than Expire stops answering for the zone entirely, on the grounds that its data is too stale to trust. With two weeks as a typical value this is rare, but it turns a long primary outage into a complete zone outage rather than a slowly ageing one.
Is the MNAME field the server I should query?
Not necessarily. MNAME names the primary — where updates originate — and it may not even appear in the NS set (a hidden primary). For lookups, use the servers from an NS lookup; those are the ones resolvers actually talk to.

Related guides

Why Is My DNS Not Propagating?

A checklist for records that refuse to update: caching, wrong zone, and stale nameservers.

Lower Your TTL Before a DNS Migration

The TTL-lowering timeline that makes DNS cutovers near-instant.