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         ; Minimum TTL (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}'

The MNAME should be a server that actually serves the zone and accepts zone transfer requests. It does not need to be the same as the NS records listed for the zone, but it typically is one of them.

In DNScale's architecture, the MNAME is set to the primary nameserver that handles zone updates. Edge nodes receive updates via real-time replication rather than traditional zone transfers, so the MNAME is primarily informational for external consumers.

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)

Despite the name "minimum," this field specifically controls how long resolvers cache negative responses — answers that say a name doesn't exist (NXDOMAIN) or a record type doesn't exist (NODATA). This is defined by RFC 2308.

How the SOA Record Works

Zone Authority

The SOA record declares which name server is the primary authority for a zone. When DNS resolvers need to find the authoritative answer for a domain, the SOA tells them where to look.

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

AXFR transfers the entire zone, while IXFR (Incremental Zone Transfer) only sends changes since a given serial number. IXFR is more efficient for large zones with small changes. The secondary specifies its current serial in the IXFR request so the primary knows what to send.

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 minimum TTL field controls how long resolvers cache negative responses. When someone queries a name that doesn't exist, the NXDOMAIN answer is cached for this duration, reducing unnecessary queries to your authoritative servers.

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 minimum TTL duration. They won't see the new record until that cache expires.

# Check the negative caching TTL
dig SOA example.com +short | awk '{print $7}'
 
# Test what happens when querying a non-existent name
dig nonexistent.example.com
# The AUTHORITY section will show the SOA with the minimum TTL

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 format is human-readable and supports up to 99 changes per day. It's the most widely used convention and makes it easy to see when a zone was last updated.

Unix Timestamp

Some systems use Unix timestamps as serial numbers:

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

This supports many more changes per day and is easy to generate programmatically. However, it's less human-readable.

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

Since the serial number is a 32-bit integer, the maximum value is 4,294,967,295. RFC 1982 defines serial number arithmetic to handle wraparound, but in practice, if you use date-based serials, you won't hit this limit for thousands of years.

Be careful when manually editing serial numbers. If you accidentally set a serial too high and then try to go back to a lower number, secondaries will think the zone hasn't changed. The safest fix is to set the serial to the maximum value (4294967295), wait for propagation, then set it to 0 and wait again, then set your desired value.

Recommended SOA Values

RFC 2308 recommends a negative caching TTL between 1 and 3 hours. Going below 60 seconds can increase load on your authoritative servers significantly.

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

If the serial numbers match, your secondary is in sync.

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
 
# Check SOA at the TLD level (to verify delegation)
dig SOA example.com @$(dig NS com. +short | head -1)
 
# 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, ensuring faster propagation than traditional AXFR-based transfers
• 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. Use at least 1 week (604800 seconds). 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. This is a common cause of the DNS_PROBE_FINISHED_NO_INTERNET error in browsers.

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.

Related Record Types

• NS Records — define which nameservers are authoritative for a zone
• What Is a DNS Zone — understand zones and their structure
• DNS Record Types — overview of all DNS record types
• System Records — why SOA and apex NS records are protected from modification
• What Is Secondary DNS — how secondary servers use SOA for synchronization
• DNS Propagation Explained — how SOA timing affects propagation speed
• What Is TTL — understanding time-to-live values
• DNS TTL Best Practices — choosing optimal TTL values

Conclusion

The SOA record is the control center of every DNS zone. Its seven fields govern zone transfers, negative caching behavior, and authority 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.