What Is an SOA Record? The DNS Zone's Control File Explained

Every DNS zone begins with the same record type, regardless of registrar, hosting provider, or domain age. Before a single A record or MX record appears, the zone file opens with an SOA — Start of Authority. It is DNS’s control plane in a single line of text.

This article dissects every field in an SOA record, explains how they interact, and shows you the real-world consequences of misconfiguring them.

What an SOA Record Looks Like

Run a DNS lookup for any domain’s SOA and you’ll see something like this:

domainscan.in.  3600  IN  SOA  ns1.domainscan.in.  hostmaster.domainscan.in.  (
    2026082101  ; serial
    7200        ; refresh
    3600        ; retry
    1209600     ; expire
    300         ; minimum TTL
)

Seven pieces of data. Each one controls a different aspect of how DNS zone data propagates and caches across the internet.

Field-by-Field Breakdown

MNAME — Primary Nameserver

ns1.domainscan.in.

The MNAME (master name) field names the single primary nameserver for this zone. When a DNS record changes, this is the server that receives the update first.

Secondary nameservers watch this server’s serial number. When they detect a change, they initiate a zone transfer from this host. This means MNAME must be network-reachable from your secondary nameservers — a common oversight when switching DNS providers.

Note the trailing dot. DNS names in zone files are fully qualified. ns1.domainscan.in (no trailing dot) would be interpreted as ns1.domainscan.in.domainscan.in — a completely different hostname.

RNAME — Responsible Administrator Email

hostmaster.domainscan.in.

This is the email address of the DNS zone administrator, encoded as a DNS name: the first dot is replaced with @. So hostmaster.domainscan.in. means hostmaster@domainscan.in.

RNAME is rarely checked automatically, but it’s what registrars and IANA use when they need to contact the zone administrator about a technical problem. hostmaster is the RFC-recommended local part; admin and webmaster are also common.

If your email address contains a dot before the @ (like a.b@example.com), it must be escaped with a backslash: a\.b.example.com.

Serial Number

2026082101

The serial number is a 32-bit unsigned integer used as a version number for the zone. Secondary nameservers compare their stored serial against the primary’s. If the primary’s serial is strictly greater (using sequence number arithmetic per RFC 1982), secondaries initiate a zone transfer.

The most common format is YYYYMMDDnn — date plus a two-digit sequence number. 2026082101 means August 21, 2026, first revision of the day. This lets you make up to 99 changes per day before needing a different format.

Critical rule: every time you change any record in the zone, increment the serial. Forget this and your secondaries will serve stale data, often silently.

Some DNS control panels increment the serial automatically. If yours does, don’t edit it manually.

Refresh

7200  (2 hours)

How often secondary nameservers poll the primary to check if the serial has changed. Lower values mean faster propagation when records change, but more DNS server traffic.

Typical values:

• Busy zones with frequent changes: 3600 (1 hour)
• Standard production zones: 7200–14400 (2–4 hours)
• Stable zones: 86400 (24 hours)

Modern managed DNS providers often push zone updates to secondaries instead of waiting for the refresh poll, making this field less critical than it was in the 1990s.

Retry

3600  (1 hour)

If a secondary fails to reach the primary during a refresh poll, it waits this many seconds before trying again. Should always be less than Refresh. A standard ratio is Retry = Refresh / 2.

Expire

1209600  (14 days)

If a secondary cannot reach the primary for this duration (continuously), it stops serving the zone entirely — it considers its data too stale to be authoritative. This prevents a secondary from indefinitely serving data that may be badly out of date.

RFC 1912 recommends at least 2 weeks. Setting this too low (say, a few hours) means a brief primary outage can take your entire secondary DNS infrastructure offline.

Minimum TTL (Negative Cache TTL)

300  (5 minutes)

This field changed meaning in 1998. Originally it was the default TTL for records that didn’t specify their own. After RFC 2308, it became the negative cache TTL — how long resolvers cache NXDOMAIN responses (lookups for names that don’t exist).

Modern DNS software uses the SOA TTL field for the record’s own cache lifetime, and this Minimum field solely for NXDOMAIN caching.

Practical impact: if you set this to 86400 and someone queries a typo subdomain, resolvers cache the “doesn’t exist” answer for a full day. When you then create that subdomain, many users will still get NXDOMAIN for up to 24 hours.

Recommended: 300–900 seconds for zones that change occasionally. Use lower values only if you’re actively migrating records.

The SOA Record and Zone Transfers

Zone transfers (AXFR for full transfers, IXFR for incremental) are how secondary nameservers receive zone data. The SOA serial number is the synchronization mechanism:

Secondary → Primary: "What's your SOA serial?"
Primary → Secondary: "2026082101"
Secondary: "I have 2026082002, your serial is higher — send me the zone."
Primary → Secondary: [full or incremental zone data]

This poll happens every Refresh seconds. If the serial hasn’t changed, no transfer occurs.

For DNSSEC-signed zones, zone transfers also replicate RRSIG records. The SOA record itself is signed, making serial tampering detectable.

Common SOA Misconfigurations

1. Forgetting to increment the serial

The most common mistake. Your DNS provider’s UI may show the record updated, but secondary nameservers never receive it because the serial didn’t change.

# Check current serial
dig SOA domainscan.in +short

# Should output the full SOA record with current serial

2. Serial number going backwards

If you restore a DNS backup or copy a zone file from a test environment, the serial might be lower than what secondaries already have. They’ll refuse to accept the transfer.

Fix: set the serial to a value strictly greater than what secondaries hold. If you don’t know what they hold, add 2147483647 to the current value and wrap around — or use the YYYYMMDDnn format starting from today.

3. Expire shorter than Refresh

If Expire < Refresh, a secondary might expire the zone before it successfully completes a refresh cycle. Zone stops being served.

Always maintain: Expire >> Retry >> Refresh (in terms of time duration).

4. Unreachable MNAME

If the MNAME hostname doesn’t resolve or isn’t network-reachable, zone transfers fail silently. Secondary nameservers log errors; you don’t notice until your secondaries are days behind your primary.

Check with:

dig SOA yourdomain.com +short | awk '{print $1}'
# Then verify that hostname resolves and port 53 is open

Checking an SOA Record

# Standard lookup
dig SOA domainscan.in

# Short output (just the data fields)
dig SOA domainscan.in +short

# Trace the query path
dig SOA domainscan.in +trace

# Verify both nameservers return the same serial
dig @ns1.domainscan.in SOA domainscan.in +short
dig @ns2.domainscan.in SOA domainscan.in +short

Comparing serials across your nameservers is the fastest way to catch propagation problems.

SOA and DNSSEC

In DNSSEC-signed zones, the SOA record gets an RRSIG signature. The serial number inside the SOA is critical for DNSSEC key rollover timing:

• Zone signing keys (ZSK) are typically rotated every 30–90 days
• Each rotation requires zone re-signing with an incremented serial
• If secondary nameservers are behind (low serial), they’ll serve signatures that don’t match the current zone, causing SERVFAIL errors for resolvers that validate DNSSEC

This is why DNSSEC deployments require reliable zone transfer infrastructure even more than unsigned zones.

Quick Reference

The SOA record is one line, but it touches every aspect of how your DNS zone propagates across the internet. Getting the serial increment habit right and setting sensible TTLs prevents the most common DNS propagation headaches before they happen.