Zones vs Domains: An Important Distinction
A zone and a domain are related but not the same thing. A domain is a node in the DNS namespace hierarchy — a name like example.com. A zone is an administrative unit that defines a contiguous portion of that namespace under a single organization's management authority.
In the simplest case, the example.com zone contains all DNS records for example.com and all its subdomains. But zones can be split: the example.com zone might cover the apex and most subdomains, while sub.example.com is delegated out to a separate zone managed by a different team or DNS provider. When a subdomain is delegated, the parent zone's authority for that portion of the namespace ends, and the child zone takes over. The boundary between zones is marked by NS records and confirmed by the presence of an SOA record at the top of the child zone.
What a Zone File Contains
A zone file is a plain text file in BIND master file format (defined in RFC 1035) that lists every DNS record in the zone. Each line is a resource record. The file begins with an SOA record and NS records, followed by all the A, AAAA, CNAME, MX, TXT, and other records for the zone.
A minimal zone file for example.com looks like this: the SOA record defines zone metadata; NS records list the authoritative nameservers; A records map hostnames to IPv4 addresses; AAAA records map to IPv6; MX records identify mail servers; CNAME records create aliases; TXT records hold arbitrary text data (used for SPF, DKIM, domain verification, and other purposes).
Modern managed DNS providers (Cloudflare, Route 53, Google Cloud DNS) abstract away the raw zone file format behind a web interface or API, but the underlying data model is the same. Understanding the zone file format helps when importing, exporting, or debugging DNS configurations.
The SOA Record
The Start of Authority (SOA) record is the first record in every zone file. It defines the zone itself and contains administrative metadata that secondary nameservers use to manage zone synchronization. Every zone has exactly one SOA record, located at the zone apex (the root of the zone).
The SOA record contains six timing and identification fields in addition to the primary nameserver and the responsible party's email address (written with the first dot replaced by an at-sign, so admin@example.com becomes admin.example.com. in the SOA). The six fields are: serial number (zone version), refresh interval (how often secondaries check for updates), retry interval (how often secondaries retry after a failed refresh), expire time (how long secondaries serve stale data before giving up), and minimum TTL (used as the default TTL for records without an explicit TTL and as the negative caching TTL for NXDOMAIN responses).
Zone Delegation and Glue Records
DNS authority is delegated downward through the hierarchy using NS records. When you register example.com, your registrar adds NS records to the .com TLD zone pointing to your authoritative nameservers. This tells resolvers where to find authoritative answers for your domain.
You can further delegate subdomains. To delegate sub.example.com to a different set of nameservers, you add NS records in your example.com zone pointing to the nameservers that will be authoritative for the subdomain. Those nameservers must host a zone that starts with an SOA record at sub.example.com.
Glue records are required when the nameserver hostname is within the zone being delegated. If you delegate sub.example.com to ns1.sub.example.com, a resolver trying to find ns1.sub.example.com would need to query the sub.example.com zone — which it cannot do without first finding ns1.sub.example.com. This circular dependency is broken by adding an A record for ns1.sub.example.com directly in the parent (example.com) zone. This out-of-zone A record is the glue record.
Primary and Secondary Zones
A primary zone is the authoritative source of truth for a zone's DNS records. Changes are made to the primary zone, and the primary nameserver serves queries from this canonical data. A secondary zone is a read-only copy of the zone maintained by a secondary nameserver through a process called zone transfer.
Secondary nameservers exist for redundancy and performance. Domain registrars typically require at least two nameservers for a domain. If the primary nameserver goes offline, secondaries continue answering queries from their synchronized copy of the zone. Secondaries located in different geographic regions also reduce query latency for globally distributed users.
Secondary servers periodically poll the primary's SOA serial number. When the primary's serial is higher than the secondary's, the secondary initiates a zone transfer to sync the new records. The refresh interval in the SOA record controls how frequently this check occurs.
Zone Transfers: AXFR and IXFR
Zone transfers are the mechanism by which secondary nameservers receive copies of zone data from the primary. There are two transfer types defined in the DNS protocol.
AXFR (Authoritative Full Zone Transfer) transfers the entire zone — every record — in a single TCP session. AXFR is always available and is the fallback when incremental transfer is not possible. For large zones with thousands of records, a full AXFR consumes more bandwidth and time than necessary when only a few records changed.
IXFR (Incremental Zone Transfer) transfers only the records that changed since the secondary's last known serial number. The secondary sends its current serial to the primary, and the primary responds with only the deltas. IXFR reduces transfer size significantly for frequently updated zones. If the primary does not have delta history going back to the secondary's serial (because the primary was rebuilt or the history was purged), it falls back to a full AXFR.
Zone transfers must be restricted to authorized secondary nameserver IP addresses. An open AXFR allows anyone to download your entire zone file, exposing every hostname and IP address in your infrastructure. Use the allow-transfer directive in BIND or equivalent settings in other DNS software to limit zone transfers to known secondary IPs.
TSIG Keys for Authenticated Zone Transfers
IP-based restrictions on zone transfers can be bypassed if an attacker spoofs the source IP of an authorized secondary. TSIG (Transaction Signature) keys add a layer of cryptographic authentication to DNS transactions including zone transfers. Both the primary and secondary are configured with a shared secret key. Each DNS message in the transfer is signed with an HMAC using that key, and the recipient verifies the signature before accepting the data.
TSIG is also used to authenticate dynamic DNS updates — the mechanism by which DHCP servers and other systems automatically update DNS records. Without TSIG, any host on the network could send DNS UPDATE messages and modify zone records.
DNS Hosting vs Domain Registrar
A domain registrar is the company through which you register a domain name and pay the annual renewal fee. A DNS hosting provider is the company that operates the authoritative nameservers that host your zone and answer DNS queries. These are separate services and can be handled by separate companies.
When you register a domain, the registrar sets the NS records in the TLD zone pointing to nameservers you designate. If you want to use Cloudflare for DNS hosting, you update the NS records at your registrar to point to Cloudflare's nameservers, then manage your zone records in Cloudflare's DNS management interface. The registrar only needs to know which nameservers are authoritative — it does not store or serve your zone records itself.
SOA Record Fields
| Field | Purpose | Example Value | What Happens When Wrong |
|---|---|---|---|
| Primary NS | Hostname of the primary nameserver | ns1.example.com. | Secondary servers cannot find the primary for zone transfers |
| Responsible email | Admin contact (@ replaced with .) | admin.example.com. | Informational only; no operational impact |
| Serial number | Zone version; secondaries sync when this increments | 2026050101 | Secondaries do not transfer updated records if serial is not incremented |
| Refresh interval | How often secondaries poll for serial changes (seconds) | 3600 | Too high: slow propagation to secondaries; too low: excess polling load |
| Retry interval | How often secondaries retry after a failed refresh (seconds) | 900 | Too high: secondaries stay out of sync after a primary outage |
| Expire time | How long secondaries serve stale data before stopping (seconds) | 604800 | Too low: secondaries stop answering queries during extended primary outages |
| Minimum TTL | Default TTL and negative caching TTL for NXDOMAIN (seconds) | 300 | Too high: NXDOMAIN responses cached too long; too low: excess negative lookup traffic |
Frequently Asked Questions
What is the difference between a DNS zone and a domain?
A domain is a node in the DNS namespace — a name like example.com. A zone is an administrative unit of control over part of that namespace. A single domain and its zone often coincide, but they are not the same thing. One zone can cover multiple subdomains (e.g., example.com and all its subdomains), or a subdomain can be delegated out into its own separate zone managed by a different organization. A zone is defined by where authority starts and stops — marked by NS records and SOA records — rather than by the domain name itself.
What does the SOA serial number do?
The SOA serial number is a version number for the zone file. Secondary nameservers compare their copy of the serial number against the primary nameserver's serial number to determine whether their zone data is current. If the primary has a higher serial number, the secondary initiates a zone transfer to fetch the updated records. The conventional format is YYYYMMDDNN (year, month, day, two-digit revision counter), but any monotonically increasing integer works. Forgetting to increment the serial number after editing a zone file is a common mistake that prevents secondary servers from picking up the changes.
What is an AXFR zone transfer?
AXFR (Authoritative Transfer) is the DNS protocol mechanism for transferring a complete copy of a zone from a primary nameserver to a secondary nameserver. When a secondary server detects that the primary has a higher SOA serial number, it initiates an AXFR request to download all records in the zone. AXFR transfers the entire zone every time, regardless of how many records changed. IXFR (Incremental Zone Transfer) is a more efficient variant that transfers only the records that changed since the secondary's last known serial number.
Why should zone transfers be restricted?
An unrestricted AXFR zone transfer allows anyone on the internet to download every DNS record in your zone in a single request. This is an information disclosure vulnerability — it reveals every hostname, IP address, mail server, and service endpoint you have configured, giving attackers a complete map of your infrastructure. Zone transfers should be restricted to the IP addresses of your authorized secondary nameservers using the allow-transfer directive in BIND or equivalent settings in other DNS server software. TSIG (Transaction Signature) keys add cryptographic authentication to zone transfers for additional security.
What is a secondary DNS zone?
A secondary DNS zone is a read-only copy of a zone maintained by a secondary nameserver. The secondary server periodically checks the primary nameserver's SOA serial number and performs a zone transfer (AXFR or IXFR) when the serial has incremented. Secondary zones provide redundancy — if the primary nameserver goes offline, secondary servers continue answering queries from their cached copy of the zone. Most domain operators publish at least two authoritative nameservers (one primary, one or more secondaries) to meet the redundancy requirements of domain registrars and to improve query response times globally.
How do I delegate a subdomain to a different nameserver?
To delegate a subdomain to a different nameserver, add NS records in the parent zone pointing to the nameservers that will be authoritative for the subdomain. For example, to delegate sub.example.com to ns1.otherprovider.com, add an NS record in the example.com zone: sub.example.com. IN NS ns1.otherprovider.com. If the delegated nameserver's hostname is within the subdomain being delegated (a glue record situation), you must also add an A record for that nameserver in the parent zone so resolvers can find it without a circular dependency.