What is a DNS SOA record?

DNS
Published by

If you have ever dug into a domain's DNS records with dig or an online lookup tool, you have probably spotted an SOA record without knowing what it was for. It is one of the most critical records in any DNS zone: it defines who holds authority over that zone, how secondary DNS servers should synchronise, and how long data stays valid if the primary goes down.

What an SOA record contains

SOA stands for Start of Authority. Every DNS zone must contain exactly one SOA record. It always sits at the apex of the zone and holds seven distinct fields. Here is what a typical SOA record looks like:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Breaking down each field:

  • MNAME (ns1.example.com.): the primary authoritative DNS server for the zone. This is the server that secondary servers contact to pull updates
  • RNAME (admin.example.com.): the email address of the zone administrator, but with a dot replacing the @. Here it translates to [email protected]. If the local part contains a dot, it must be escaped with a backslash (first\.last.example.com.)
  • Serial (2025052901): a version number for the zone. Every change must increment this number, otherwise secondary servers will not detect the update. The common format is YYYYMMDDNN (date plus a daily counter)
  • Refresh (7200): the interval in seconds between checks by secondary servers. Here, every 2 hours
  • Retry (3600): how long a secondary waits before retrying if a Refresh check fails. Here, 1 hour
  • Expire (1209600): the time after which a secondary stops answering for the zone if it can no longer reach the primary. Here, 14 days. Past this point, the secondary considers its data stale and stops serving the zone entirely
  • Minimum TTL (86400): since RFC 2308, this field sets how long negative responses (NXDOMAIN) are cached. Here, 24 hours. If someone queries a subdomain that does not exist, the resolver caches that "does not exist" answer for 24 hours

Why the serial number matters so much

The serial is probably the field that causes the most trouble in practice. When a secondary server contacts the primary during a Refresh cycle, it compares its local serial with the primary's. If the primary's serial is higher, the secondary initiates a zone transfer (AXFR or IXFR) to update itself. If the serial has not changed, it does nothing.

The classic mistake: editing a DNS record on the primary without incrementing the serial. The primary has the correct version but secondaries keep serving the old one for hours or days. Users get different answers depending on which server they hit, and the problem is hard to diagnose if nobody thinks to check the SOA.

The YYYYMMDDNN format is a convention, not a requirement. The serial is a 32-bit integer, so any value from 0 to 4,294,967,295 works. But the date format is recommended because it makes mistakes visible: a serial of 2025052901 is clearly the first change made on 29 May 2025.

How Refresh, Retry and Expire work together

These three values form a resilience system for DNS zones. Refresh sets the normal sync rhythm. Retry kicks in when a Refresh check fails. Expire is the ultimate safety net: beyond this period without contact with the primary, the secondary would rather stop answering entirely than serve potentially outdated data.

For a standard domain, RFC 1912 recommends:

  • Refresh: 3,600 to 86,400 seconds (1 hour to 24 hours)
  • Retry: 600 to 3,600 seconds (10 minutes to 1 hour)
  • Expire: 1,209,600 to 2,419,200 seconds (2 to 4 weeks)
  • Minimum TTL: 3,600 to 86,400 seconds (1 hour to 24 hours)

If your zone changes frequently (for example a CDN or an infrastructure with dynamic load balancing), drop the Refresh to 300 or 600 seconds. If it is stable, 86,400 works perfectly well and reduces load on the primary server.

How to check a domain's SOA record

On Linux and macOS, dig is the easiest option:

dig SOA example.com

On Windows, use nslookup:

nslookup -type=SOA example.com

The response shows all seven SOA fields. Pay particular attention to the serial: if it looks old or frozen, it is often the reason DNS changes are not propagating properly.

Common SOA mistakes

A few issues that come up regularly in practice:

  • The RNAME uses an @ instead of a dot, which breaks the syntax. [email protected] must be written as admin.example.com. in the SOA
  • The serial gets accidentally decremented after restoring a backup. Secondaries will refuse to sync until the primary's serial climbs back above their local value
  • Expire is set too short (a few hours). If the primary goes down over a weekend, secondaries stop answering before anyone can intervene
  • Minimum TTL is set to 0, meaning resolvers do not cache negative responses. Every query for a non-existent subdomain triggers a full round trip, which can overload your DNS servers during a scan or attack
The SOA record is rarely the first thing you edit when setting up a domain, but it is often the one that explains why "DNS changes aren't propagating". Before looking for complex causes, check that the serial was properly incremented and that the Refresh and Expire values suit your setup.