The DNS hierarchy, zones and delegation
Zones and zone files, NS records and delegation, the SOA fields that actually matter, glue records, and why a zone is not the same thing as a domain.
Zones, not domains
A domain is a name. A zone is a portion of the namespace that one set of nameservers is authoritative for and that is stored in one file. The two coincide only at the apex - example.com is both a domain and a zone - and diverge as soon as you delegate a subdomain to different servers.
| Term | Meaning | Example |
|---|---|---|
| Domain | A name in the hierarchy | api.example.com |
| Zone | A file, served authoritatively by one set of servers | example.com and everything not delegated below it |
| Apex | The root of a zone, also called the origin | example.com itself |
| Delegation | Handing a subtree to other nameservers | NS api.example.com -> ns1.other.net |
| Glue | Address records published by the parent for in-zone nameservers | The A record for ns1.example.com inside the parent |
| Authority | The right to answer authoritatively for a zone | The servers listed in the delegation |
; a minimal zone file for example.com
$ORIGIN example.com.
$TTL 3600
@ IN SOA ns1.example.com. hostmaster.example.com. (
2026091801 ; serial: bump on every change
7200 ; refresh: how often secondaries poll
3600 ; retry after a failed refresh
1209600 ; expire: give up after two weeks
300 ) ; negative TTL: how long NXDOMAIN is cached
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 203.0.113.10
www IN CNAME @
ns1 IN A 203.0.113.11
ns2 IN A 203.0.113.12- The serial number must increase on every change. A primary that publishes a lower serial than a secondary causes the secondary to refuse the transfer.
- The last SOA field is the negative caching TTL - how long a resolver remembers that a name does not exist. It is the reason a typo can appear to be cached for hours.
@means the origin.@ IN Ais the apex address record, which cannot be a CNAME.
Delegation and glue
; in the parent zone, delegating a subdomain
api IN NS ns1.api.example.com.
api IN NS ns2.api.example.com.
; glue: the parent publishes addresses for nameservers inside the delegated zone,
; otherwise resolving ns1.api.example.com would require resolving api.example.com
ns1.api IN A 203.0.113.21
ns2.api IN A 203.0.113.22- The parent publishes NS records for the child. That is the whole delegation mechanism.
- If the child's nameservers are inside the child zone, the parent must also publish glue, or the lookup is circular and fails.
- From that point the parent no longer answers for anything under
api- the child does, and a record left in the parent is ignored. - Removing the delegation without changing the child's records leaves the child authoritative but unreachable.
# who is actually answering, and where does the chain break?
dig +trace api.example.com
dig NS api.example.com @a.gtld-servers.net # ask the parent directly
dig SOA example.com +short
dig +norecurse api.example.com @ns1.api.example.com # ask the child directly💡
The single most useful habit in DNS work is querying the server you think should know the answer rather than your own resolver.
+norecurse against the authoritative server shows you what is published; asking a recursive resolver shows you what it happened to cache.FAQ
Can one domain have two zones?
Yes - that is what delegation is.
example.com is one zone and api.example.com is another, with a different nameserver set. Records in the parent for names under the child are ignored.Why did my change appear on one resolver but not another?
Different resolvers hold different cached copies with different remaining TTLs. Query the authoritative servers to confirm what is published, then wait out the longest TTL you had set.
Related
How name resolution works Subdomains, wildcards and delegation strategies
Last refreshed 2026-09-18.