SOA Records: Zone Authority Configuration

## What the SOA Record Controls The SOA Record (Start of Authority) is the first mandatory record in every DNS zone. It serves two distinct purposes: it identifies the primary authoritative nameserver and the administrative contact for the zone, and it sets timing parameters that govern zone replication between primary and secondary Nameserver servers. Every DNS operator needs to understand SOA because its parameters directly affect: - How quickly changes propagate from primary to secondary servers - How long secondary servers continue to serve a zone if the primary is unreachable - How long resolvers cache negative (NXDOMAIN) answers for your domain ## The Seven SOA Fields ``` $ORIGIN example.com. @ IN SOA ns1.example.com. hostmaster.example.com. ( 2024020601 ; 1. Serial 7200 ; 2. Refresh (seconds) 3600 ; 3. Retry (seconds) 1209600 ; 4. Expire (seconds) 300 ; 5. Minimum / Negative TTL (seconds) ) ``` ### 1. MNAME — Primary Nameserver `ns1.example.com.` — The primary master nameserver for this zone. Secondary servers use this to find where to request zone transfers (AXFR) and NOTIFY messages. MNAME should be the actual primary, not a load-balanced virtual hostname, because secondary servers need to establish direct connections to it for zone transfer. ### 2. RNAME — Responsible Person Email `hostmaster.example.com.` — The email address of the DNS administrator, encoded as a DNS name. The first dot (before the domain) represents `@`. So `hostmaster.example.com.` translates to `[email protected]`. If the username contains a dot (e.g., `[email protected]`), the dot in the username must be escaped with a backslash: `john\.doe.example.com.` RFC 2142 recommends `hostmaster@` as the standard administrative address for DNS. Using this convention makes automated tools and abuse handlers more effective. ### 3. Serial Number The serial number is a 32-bit unsigned integer that identifies the zone's version. Secondary servers compare their cached serial against the primary's current serial via periodic SOA queries. If the primary's serial is higher, the secondary initiates a zone transfer. **Serial must always increase**. If you accidentally set a lower serial (e.g., after restoring from backup), secondaries will think they are up-to-date and stop fetching updates. Three standard serial conventions: ``` YYYYMMDDNN → 2024020601 (date-based, most readable, max 99 changes/day) Unix stamp → 1707177600 (epoch seconds, auto-increment) Simple int → 1, 2, 3... (simple, loses date context) ``` Date-based serials (`YYYYMMDDNN`) are the industry standard. The `NN` suffix (01–99) handles multiple changes per day. If you exceed 99 changes in one day, increment to `NN=00` of the next day's prefix. **Serial rollover**: The serial is compared using "sequence space arithmetic" (RFC 1982). Numbers wrap around at 2^32. For most operators this is never a concern. If you ever need to reset a runaway serial (e.g., someone set it to a Unix timestamp accidentally on a date-serial system), the safe approach is incrementing past the high value until you naturally exceed it. ### 4. Refresh ``` 7200 ; 2 hours ``` How often secondary servers should check the primary's SOA record to see if the serial has changed. After `Refresh` seconds, secondaries issue a SOA query to MNAME. If the serial has increased, they initiate a full zone transfer (AXFR) or incremental transfer (IXFR). Modern DNS networks often supplement periodic refresh with NOTIFY messages (RFC 1996), where the primary proactively notifies secondaries immediately after a zone change. With NOTIFY, the Refresh timer is a fallback rather than the primary propagation mechanism. **Recommended values**: - High-change zones (automation, frequent updates): 300–3600 seconds - Low-change zones (stable production): 3600–14400 seconds ### 5. Retry ``` 3600 ; 1 hour ``` If a secondary cannot reach the primary to check for updates (primary is down, network issue), Retry sets how long to wait before trying again. Should be less than Refresh; a common ratio is Retry = Refresh / 2. ### 6. Expire ``` 1209600 ; 14 days ``` If a secondary cannot reach the primary for this many seconds total, the secondary stops serving the zone entirely and returns SERVFAIL. This prevents stale data from being served indefinitely when the primary is permanently gone. 14 days (1,209,600 seconds) is the RFC 1537 recommendation and the most common production value. For critical infrastructure, some operators use 30 days (2,592,000). The Expire value should be significantly larger than the maximum expected primary outage duration. **Expire must be larger than Refresh + Retry by a substantial margin** to avoid the secondary expiring the zone during brief network disruptions. RFC 1912 recommends: `Expire >= 7 × Refresh`. ### 7. Minimum / Negative Cache TTL ``` 300 ; 5 minutes ``` Despite the field name "Minimum TTL," RFC 2308 redefined this field to be the **Negative Cache TTL** — how long resolvers cache NXDOMAIN responses (and NODATA responses) for your zone. This is separate from the positive TTL (Time To Live) values on individual resource records. A resolver that gets NXDOMAIN for `nonexistent.example.com` caches that negative answer for `Minimum` seconds. Setting this too high means legitimate new subdomains face resolution failures for hours after creation. Too low increases query load. **Recommended values**: - Active zones with frequent subdomain additions: 60–300 seconds - Stable zones: 300–900 seconds - The SOA Minimum field should not exceed 3600 seconds (RFC 2308 Section 5) ## SOA and Zone Transfer Mechanics When a secondary detects the serial has increased (via SOA poll or NOTIFY), it requests a DNS Zone File transfer from the primary Nameserver: **AXFR (Full zone transfer)**: Transfers the entire zone. Used for initial zone load and when IXFR is unavailable. **IXFR (Incremental transfer, RFC 1995)**: Transfers only changed records since the secondary's current serial. Much more efficient for large zones with small incremental changes. ```bash # Request an AXFR (zone dump) dig @ns1.example.com example.com AXFR # Check if IXFR is supported dig @ns1.example.com example.com IXFR=2024020501 # Query the SOA record of primary and secondary and compare serials dig SOA example.com @ns1.example.com +short dig SOA example.com @ns2.example.com +short ``` ## Common SOA Misconfigurations **Serial not incrementing**: The most common BIND and PowerDNS mistake. After editing a zone file, if the serial number is not manually incremented, secondaries never fetch the update. **Refresh too high without NOTIFY**: If NOTIFY is disabled and Refresh is set to 24 hours, zone changes take up to 24 hours to propagate to secondaries. Always verify NOTIFY is enabled and functioning. **Negative TTL too high**: Setting `Minimum` to 86400 (1 day) means that any NXDOMAIN (typo, deleted record, or new subdomain not yet added) is cached for 24 hours. New deployments that create subdomains on-demand will face extended propagation delays. **MNAME pointing to a load-balanced hostname**: Secondary servers need a direct TCP connection to the primary for zone transfer. A round-robin hostname that might resolve to a secondary (creating a loop) or a different server than expected will cause zone transfer failures. For the complete DNS Zone File format that the SOA record anchors, see Zone Files: Structure and Management. For how TTL (Time To Live) interacts with DNS Propagation and secondary sync, see DNS Performance Optimization at Scale. For self-hosted Nameserver configuration around SOA parameters, see Running Your Own DNS Server: BIND vs PowerDNS. DNS Record Helper