The SOA record (Start of Authority) is the foundational DNS entry that defines the administrative and operational parameters for a DNS zone. It specifies the primary name server, the email of the zone administrator, and critical timing values for zone replication and consistency.
Every DNS zone must have exactly one SOA record. It appears at the top of the zone file and is required for zone transfers between primary and secondary name servers. Without it, DNS delegation cannot function reliably.
The SOA record contains five core components: Serial Number, Refresh Interval, Retry Interval, Expire Time, and Minimum TTL. These values govern how often secondary servers check for updates, how long they wait before retrying failed checks, how long they retain zone data if unreachable, and the default time-to-live for cached records.
When a secondary name server queries a primary server, it compares the Serial Number in the SOA record. If the primary's serial is higher, the secondary initiates a zone transfer (AXFR or IXFR) to update its copy. This ensures all authoritative servers maintain synchronized data.
For example, if the primary server's SOA serial is 2024040501 and the secondary has 2024040500, the secondary requests a full zone transfer. After successful transfer, the secondary updates its serial and begins monitoring for future changes.
If the primary becomes unreachable, the secondary uses the Retry value (e.g., 600 seconds) to determine when to reattempt contact. If no response occurs within the Expire time (e.g., 86400 seconds), the secondary stops answering queries for the zone to prevent stale responses.
Each field in the SOA record serves a distinct role in maintaining DNS integrity:
| Field | Value Example | Purpose |
|---|---|---|
| Serial Number | 2024040501 | Version identifier. Incremented on each zone change. |
| Refresh | 3600 | How often secondary servers check for updates (1 hour). |
| Retry | 600 | Time to wait before retrying a failed refresh (10 minutes). |
| Expire | 86400 | Maximum time a secondary can hold stale data (24 hours). |
| Minimum TTL | 300 | Default cache duration for negative responses (5 minutes). |
The Serial Number follows a common format: YYYYMMDDNN, where NN is a daily counter. For instance, 2024040501 means April 5, 2024, first update of the day. This structure prevents conflicts and allows automated tools to detect changes reliably.
A non-obvious requirement: the Serial Number must increase with every change. If it stays the same or decreases, secondary servers ignore updates. This rule prevents accidental data rollback during configuration errors.
Many assume the SOA record controls DNS resolution speed. That's incorrect. Resolution speed depends on caching, network proximity, and recursive resolver behavior-not SOA settings.
Another confusion is equating the SOA record with the primary name server. While the SOA identifies the master server, it doesn't direct traffic. The NS record points to the authoritative name servers, while the SOA defines policy.
Some administrators believe setting very low Retry or Refresh values improves reliability. In practice, frequent polling increases load on authoritative servers and can trigger rate-limiting. A 3600-second refresh is standard for most zones.
Consider a company updating its website IP address. The DNS administrator edits the zone file, increments the Serial Number from 2024040500 to 2024040501, and reloads the zone.
Secondary servers, checking every 3600 seconds (per the Refresh value), detect the change. They initiate a zone transfer using the updated serial. Within minutes, all secondary servers reflect the new IP address.
If the primary server goes offline during this window, the secondary waits 600 seconds (Retry) before attempting again. If no response occurs within 86400 seconds (Expire), the secondary stops serving queries to avoid returning outdated data.
This process ensures consistent, timely updates across the global DNS infrastructure.
According to the Internet Engineering Task Force (IETF), the SOA record is a mandatory component of DNS zone files under RFC 1035. It establishes the foundation for zone consistency and replication.
Cloudflare's documentation confirms that all DNS providers, including AWS Route 53 and Google Cloud DNS, require a valid SOA record for zone creation. Missing or malformed SOA entries result in zone rejection during configuration.
During a 2023 outage at a major ISP, investigators traced the failure to a misconfigured SOA serial. Secondary servers failed to recognize updates, leading to inconsistent DNS responses across regions. Proper SOA management prevented similar issues in subsequent deployments.
Understanding the SOA record is essential for anyone managing DNS zones. It's not just metadata-it's the engine of zone synchronization and reliability.