What Is an SOA Record

An SOA (Start of Authority) record is a mandatory DNS record that exists at the top of every DNS zone. It defines key information about the zone, including which name server is the primary authority, the contact email of the zone administrator, and timing parameters that control how secondary DNS servers synchronize with the primary.

Every zone must have exactly one SOA record, and it's always located at the zone apex. Without an SOA record, a zone is not valid according to the DNS specification.

SOA Record Format

Every SOA record contains seven fields:

example.com.  86400  IN  SOA  ns1.dnscale.eu. admin.example.com. (
                              2026030901  ; Serial number
                              3600        ; Refresh (1 hour)
                              900         ; Retry (15 minutes)
                              1209600     ; Expire (2 weeks)
                              300         ; Negative-cache limit (5 minutes)
                              )

Field Breakdown

All SOA Fields Explained in Depth

MNAME — Primary Name Server

The MNAME field identifies the primary (master) authoritative name server for the zone. This is the server that holds the master copy of the zone data and is the source of truth for zone transfers.

# Check which server is listed as MNAME
dig SOA example.com +short | awk '{print $1}'

MNAME identifies the primary source for the zone; it can be a hidden primary absent from the public NS records. Zone transfers should be restricted to authorized secondaries. A public AXFR refusal is usually expected and does not by itself indicate a broken SOA.

RNAME — Administrator Email

The RNAME encodes the zone administrator's email address using DNS name format. The first dot replaces the @ symbol:

admin.example.com. → admin@example.com
john\.doe.example.com. → john.doe@example.com  (escaped dot in local part)

If the email address contains a literal dot before the @ sign, it must be escaped with a backslash in the RNAME field.

Serial Number

The serial number is a 32-bit unsigned integer that must increase with every zone change. Secondary servers compare serial numbers to decide whether they need to fetch updated zone data.

Refresh Interval

Controls how frequently secondary DNS servers check the primary for updates. After each refresh interval, the secondary queries the primary's SOA record and compares serial numbers.

Retry Interval

If a secondary server can't reach the primary during a refresh, it waits the retry interval before trying again. This should always be shorter than the refresh interval.

Expire Timer

If a secondary server can't reach the primary for the entire expire duration, it stops serving the zone entirely. This prevents secondaries from serving extremely stale data indefinitely. RFC 1912 recommends 2 to 4 weeks.

Minimum TTL (Negative Caching TTL)

For negative responses, the initial cache lifetime is the smaller of the SOA record's own TTL and its MINIMUM field: min(SOA TTL, SOA.MINIMUM). This applies to a missing name (NXDOMAIN) or missing record type (NODATA), as specified in RFC 2308 §3. MINIMUM is not the default TTL for all records in the zone.

How the SOA Record Works

Zone Authority

The SOA describes a zone and its primary source of data. Recursive resolvers discover authoritative nameservers through NS delegations, starting with the DNS hierarchy or cached referrals. They do not use the SOA to locate those servers. A hidden primary may appear in MNAME without being listed in the public NS set.

Zone Transfers

Secondary DNS servers use SOA fields to decide when to synchronize:

1. Secondary checks the primary at the refresh interval
2. It compares the serial number — if it's higher, the zone has changed
3. The secondary initiates a zone transfer (AXFR or IXFR) to get the latest data
4. If the primary is unreachable, the secondary retries at the retry interval
5. If the primary stays unreachable past the expire time, the secondary stops serving the zone

# Simulate what a secondary does — query the SOA to check serial
dig SOA example.com @ns1.dnscale.eu +short
 
# Check if a zone transfer is possible (AXFR)
dig AXFR example.com @ns1.dnscale.eu

NOTIFY Mechanism

Modern DNS servers don't just rely on the refresh interval. The primary can send NOTIFY messages to secondaries immediately when the zone changes, triggering an instant refresh instead of waiting for the timer. This makes the refresh interval a fallback rather than the primary synchronization mechanism.

Negative Caching

The authoritative server includes an SOA in the negative response, with its TTL set to min(SOA TTL, SOA.MINIMUM). For example, an SOA TTL of 120 seconds and a MINIMUM of 300 seconds produce a 120-second negative cache lifetime. Resolver caps may shorten it further.

This matters when you're adding new records. If a user queried new.example.com before you created it, they received an NXDOMAIN that's cached for the negative TTL duration. They won't see the new record until that cache expires.

# Inspect the SOA record TTL and all seven data fields
dig example.com SOA +noall +answer
 
# Replace this with a name you know is absent in your own zone
dig nonexistent.example.com A +noall +comments +authority
# In a negative response, the SOA TTL shows the remaining negative lifetime

Serial Number Conventions

The serial number must increase with every zone change. Two common formats:

Date-Based (Recommended)

YYYYMMDDNN
2026030901  →  2026-03-09, change #01
2026030902  →  2026-03-09, change #02

This convention is human-readable. A two-digit counter provides 100 values (00–99); teams that start at 01 use 99 updates per day. High-change automation usually needs a different scheme.

Unix Timestamp

Some systems use Unix timestamps as serial numbers:

1741478400  →  2025-03-09 00:00:00 UTC

This is easy to generate, but multiple changes in one second still need distinct serials. Clock rollback must not make the serial go backwards.

Simple Incrementing

1, 2, 3, 4, ...

Simpler but gives no indication of when changes were made. DNScale automatically manages serial numbers for you when you create or update records.

Serial Number Rollover

Serials use a 32-bit wrapping space, as defined by RFC 1982. A forward increment must be smaller than 2³¹. Ordinary numeric comparison is insufficient across wraparound; a difference of exactly 2³¹ has undefined ordering.

Recommended SOA Values

These are starting points, not protocol requirements. RFC 2308 discusses 1–3 hours as sensible defaults for resolver-side negative-cache limits; it does not require every zone to publish that MINIMUM. Shorter negative TTLs allow new names to become visible sooner but can increase query load.

Querying SOA Records

Check a domain's SOA record using dig:

dig SOA example.com
 
# Output:
# example.com.  86400  IN  SOA  ns1.dnscale.eu. admin.example.com. (
#                              2026030901 3600 900 1209600 300 )

Query a specific nameserver:

dig SOA example.com @ns1.dnscale.eu

Compare serial numbers across nameservers to verify synchronization:

dig +short SOA example.com @ns1.dnscale.eu
dig +short SOA example.com @ns2.dnscale.eu

Matching serials are a useful synchronization signal. Also compare the changed records themselves: matching serials do not prove that independently managed zone data is identical.

Advanced SOA Diagnostics

# Check SOA from all listed nameservers
for ns in $(dig NS example.com +short); do
  echo "$ns: $(dig +short SOA example.com @$ns | awk '{print $3}')"
done
 
# Inspect the parent delegation (the parent does not serve the child SOA)
dig example.com NS @$(dig NS com. +short | head -1) +norecurse
 
# Measure SOA response time
dig SOA example.com +stats | grep "Query time"

SOA and DNScale

DNScale automatically manages the SOA record for every zone you create:

• Serial numbers are incremented automatically when you add, update, or delete records
• MNAME is set to the DNScale primary nameserver
• Timing parameters use sensible defaults optimized for reliability
• Zone transfers to edge nodes are handled automatically via real-time replication, independently of recursive resolver cache expiry
• SOA records are system records — they cannot be deleted or have their type changed

Common Issues

Serial Number Not Incrementing

If secondaries aren't picking up changes, the serial number may not have been updated. DNScale handles this automatically, but if you manage zones manually, always increment the serial.

Expire Too Short

If your expire value is too low and the primary goes down, secondaries will stop serving your zone quickly. Choose a window long enough for the primary outages your design must tolerate. This is particularly important for multi-provider DNS deployments where the secondary may be with a different provider.

Negative TTL Too High

A high minimum TTL means that if you create a new record, users who previously got an NXDOMAIN response will continue to see "not found" until the negative cache expires. Keep this at 300 seconds or lower for active zones. Use the NXDOMAIN guide to distinguish a cached missing name from a connectivity failure.

MNAME Mismatch

If the MNAME field points to a server that doesn't actually serve the zone, some secondary DNS implementations may fail to transfer. Ensure the MNAME server is reachable and authoritative for the zone.

Conclusion

The SOA record is the control center of every DNS zone. Its seven fields describe zone administration, secondary refresh timing, and negative caching. NS records handle delegation. Understanding each field — particularly the serial number for synchronization and the minimum TTL for negative caching — helps you troubleshoot propagation delays, zone transfer failures, and stale NXDOMAIN responses. While DNScale manages SOA records automatically with sensible defaults, knowing how the SOA works gives you the ability to diagnose issues across your entire DNS infrastructure.

References

• RFC 2308: negative caching.
• RFC 8767: serving stale DNS data.