A DNS zone is a contiguous portion of the domain name space that is administered as a single unit, with its own set of resource records, its own authoritative name servers and a single point of administrative control. In DNS, the zone is the unit of delegation: a parent zone hands authority for a name and everything below it to another zone, until that zone delegates part of its space further down.
A zone is not the same as a domain. The domain example.com includes every name beneath it, but if eu.example.com is delegated to separate servers, it forms its own zone, and the example.com zone no longer holds the records for that subtree. Understanding this boundary explains how the global DNS can be distributed across millions of independent operators.
How a DNS zone is structured
Every zone begins at its apex, also called the zone origin, such as example.com. The apex must carry an SOA record, which describes the zone and its timing parameters, and a set of NS records naming the authoritative servers. Below the apex the zone holds ordinary records such as A, AAAA, MX, TXT and CNAME for each name it serves.
Where the zone delegates a subdomain, it contains NS records at the delegation point and, when the child servers are named inside the child zone, glue records with their addresses. The parent zone is not authoritative for anything below that cut; it only points resolvers in the right direction.
The record types that define a zone itself, rather than its content, are summarized below.
| Record | Location | Purpose |
|---|---|---|
| SOA | Zone apex, exactly one | Primary server, contact, serial and timers |
| NS at apex | Zone apex | Lists the zone’s authoritative servers |
| NS at delegation | Parent zone | Hands a subdomain to another zone |
| Glue A or AAAA | Parent zone | Addresses of in-zone name servers |
| DNSKEY and DS | Apex and parent zone | Chain of trust for DNSSEC |
SOA timers and zone parameters
The SOA record controls how secondary servers keep their copies current and how long negative answers are cached. The serial number must increase on every change, commonly in the YYYYMMDDnn format, or secondary servers will not fetch the update.
| Field | Meaning | Typical range |
|---|---|---|
| Serial | Version of the zone data | Date-based or incrementing integer |
| Refresh | How often secondaries check the serial | 1 to 24 hours |
| Retry | Wait after a failed refresh | 10 minutes to 2 hours |
| Expire | When secondaries stop answering without contact | 1 to 4 weeks |
| Minimum (negative TTL) | Cache time for nonexistent names | 5 minutes to 1 day |
Each record also carries its own TTL, which tells resolvers how long they may cache it. Values between 300 seconds and 86,400 seconds are common; shorter values allow faster changes at the cost of more queries to the authoritative servers.
Zone transfers and serving models
A zone is usually served by at least two authoritative servers on separate networks. Traditionally, a primary server holds the editable zone file and secondary servers replicate it through zone transfers, triggered by NOTIFY messages and protected with TSIG keys.
| Mechanism | How it works | Typical use |
|---|---|---|
| AXFR | Full transfer of the whole zone | Initial sync, small zones |
| IXFR | Transfers only changes since a serial | Large, frequently edited zones |
| NOTIFY | Primary tells secondaries to check now | Fast propagation after edits |
| Database or API replication | Provider syncs records internally | Managed and anycast DNS services |
| Hidden primary | Unlisted primary feeds public secondaries | Protecting the editing server |
Managed DNS platforms often serve zones from anycast networks, where the same server addresses are announced from many locations. The zone concept stays the same, but replication happens through the provider’s internal systems rather than classic transfers.
Zone compared with domain and related concepts
Many DNS misunderstandings come from treating zone, domain and zone file as synonyms. They describe different things: a naming subtree, an administrative unit and a storage format.
| Term | What it is | Key difference |
|---|---|---|
| Domain | A name and all names below it | May span several zones |
| DNS zone | Administrative unit of the name space | Ends at delegation points |
| Zone file | Text representation of a zone | One storage format among several |
| Authoritative DNS server | Server that answers for a zone | Serves one or many zones |
| Recursive resolver | Looks up answers on behalf of clients | Caches zone data, owns none |
There are also special zone types. Reverse zones under in-addr.arpa and ip6.arpa map addresses back to names with PTR records, and split-horizon setups serve different versions of the same zone to internal and external clients.
Common zone configuration mistakes
Zone errors are dangerous because caching spreads a mistake for the length of the TTL, often hours. Careful validation before publishing changes prevents most incidents.
- Forgotten serial increment: secondaries keep serving old data indefinitely.
- Lame delegation: the parent lists name servers that do not actually serve the zone.
- Mismatched NS sets: parent and child list different servers, causing inconsistent answers.
- CNAME at the apex: not permitted alongside SOA and NS; use provider-specific alias records instead.
- Open zone transfers: unrestricted AXFR exposes every hostname; restrict transfers by key or address.
- Expired DNSSEC signatures: signed zones that are not re-signed in time become unresolvable for validating resolvers.
Lowering the TTL of records a day or two before a planned migration is a standard practice, so the change takes effect quickly once it is made.
In everyday language
Think of the domain name system as a huge address book split into many chapters. A DNS zone is one chapter that a single owner is responsible for. The owner decides what goes into it and keeps it up to date.
If part of the chapter becomes too big, the owner can hand it to someone else. The original chapter then contains only a note saying where to look. This sharing of responsibility is what lets the internet’s naming system grow without a central bottleneck.
Seen in the real world
A university runs the example.edu zone on two central name servers. Its medical faculty wants to manage its own hostnames for laboratory systems without filing tickets with central IT for every change.
Central IT delegates `med.example.edu` as a separate zone by adding NS records for the faculty’s two name servers, plus glue addresses because the servers sit inside the delegated name. The faculty creates the new zone with its own SOA record, a 3,600-second default TTL and IXFR replication to its secondary server.
From then on, the faculty edits laboratory records independently, while the central zone stays unchanged. Each team controls its own zone, and a configuration error in one no longer affects the other.