In DNS, what is the difference between a domain and a zone, and what makes a name server authoritative for a zone?
answer
- subtree versus administered slice
- cuts between adjacent nodes
- what sits at the zone apex
- NS set plus exactly one SOA
basics
~20 sA DNS domain is a whole subtree of names; a zone is the connected part of it that one set of servers answers for, from its apex down to any delegation. The apex SOA and NS records define the zone.
solid answer
~50 sA **domain** is a node in the DNS tree plus everything beneath it, so `example.com` includes `dev.example.com` whatever happens to it. A **zone** is the connected piece of that tree managed as one unit: it starts at its apex (the *origin*) and stops at any *zone cut*, where the parent has handed a child to other servers with `NS` records. Every zone carries one `SOA` record and an `NS` RRset at its apex (RFC 2181 §6.1). A server is authoritative for the zone when it holds the zone's own data, loaded from a zone file as the primary or copied by zone transfer as a secondary, and answers from it with the `AA` bit set; the apex `NS` set is how everyone else learns which servers those are. Once `dev.example.com` is delegated it is still inside the `example.com` domain, but no longer in the `example.com` zone.
go deeper
Recall that a domain is a subtree of names while a zone is the slice one set of servers is authoritative for, and that every zone has an SOA and NS records at its apex.
Explain cuts: the parent's NS records at a child name end its zone there, and names below belong to the child zone while staying in the parent's domain.
Use the zone boundary to reason about incidents: which servers are authoritative for the name in question, whose serial must change, and whether a listed server really serves the zone.
Frame zone boundaries as ownership boundaries: where to cut so teams change records independently, and what each extra delegation adds in servers to run and consistency to keep.
## Two words for two different things People say "the example.com domain" and "the example.com zone" as if they meant the same thing. In the DNS specifications they do not, and the difference is exactly what delegation is about. - A **domain** is a name in the DNS tree together with every name below it. `example.com` as a domain contains `www.example.com`, `dev.example.com`, `api.dev.example.com` and anything else that ends in `example.com`. Delegation cannot remove a name from its domain; the domain is defined purely by the shape of the tree. - A **zone** is a unit of *administration and authority*. RFC 1034 §4.2 describes the namespace being divided by **cuts** made between adjacent nodes; after all cuts are made, "each group of connected name space is a separate zone". The zone takes its name from its highest node, called its **origin** or **apex**. So a zone is always a connected piece of a domain, and a domain may be split across many zones. ## Where a zone stops: the zone cut A cut exists wherever a parent zone **delegates** a child. RFC 2181 §6 puts it precisely: the existence of a zone cut is shown in the parent by `NS` records at the child's origin, and "each zone comprises that subset of the DNS tree that is at or below the zone's origin, and that is above the cuts that separate the zone from its children". Take this layout: | Name | Domain it belongs to | Zone it belongs to | |---|---|---| | `www.example.com` | `example.com` | `example.com` | | `dev.example.com` (delegated) | `example.com` | `dev.example.com` | | `api.dev.example.com` | `example.com` and `dev.example.com` | `dev.example.com` | | `a.b.example.com` (no cut at `b`) | `example.com` | `example.com` | The last row matters: a zone is not limited to one label of depth. Without a delegation, `example.com` can hold names many levels deep, and the intermediate name may even own no records at all. ## What a zone is made of RFC 1034 §4.2.1 lists four kinds of data in a zone: 1. **Authoritative data** for every node from the apex down to the bottom edge of the zone. 2. **Data that defines the apex**: one `NS` record per server for the zone, and a single `SOA` record carrying the zone's management parameters (its serial number and transfer timers). 3. **Delegation data**: the `NS` records at each cut that name the child's servers. These are *not* authoritative data of the parent; RFC 2181 §6.1 calls them "the property of the child zone". 4. **Glue**: address records for child name servers whose names sit below the cut, kept only so a referral can be followed. RFC 2181 §6.1 names the `NS` records at the origin plus the `SOA` record as "the mandatory records in every zone". On disk, a zone is commonly kept as a **master file** (RFC 1035 §5), where `$ORIGIN` sets the origin for relative names, a free-standing `@` stands for that origin, and `$TTL` (added by RFC 2308) supplies a default TTL. ## What makes a server authoritative A name server is authoritative for a zone when it answers from the zone's own data rather than from a cache. It gets that data in one of two ways: - as the **primary**, by loading it from a master file or a database the administrator edits; - as a **secondary**, by copying it from another authoritative server with a zone transfer. When it answers from that data it sets the `AA` (authoritative answer) bit. A caching recursive resolver can return exactly the same record, but it is not authoritative: it is repeating what it learned. The apex `NS` RRset is how the rest of the Internet *finds* the authoritative servers, and RFC 1034 §4.1 requires every zone to be available on "at least two servers". Being listed and being authoritative are separate facts, though: - A **stealth server** holds a full copy of the zone and answers authoritatively but is not listed in the `NS` RRset (RFC 1996 §2.1); only servers configured to know about it will ask it. - A **lame** server is listed in the `NS` RRset but does not actually serve the zone, which is a misconfiguration. ## Why the distinction matters in practice - Ownership follows zones, not domains. Delegating `dev.example.com` lets another team change their records without touching the `example.com` zone file or its serial number. - Transfers, serials and timers are per zone. Changing a record in `dev.example.com` never bumps the `example.com` serial. - Debugging starts by asking "which zone holds this name?", because that decides which servers are authoritative for the answer you are looking at.
- Can a single DNS zone hold names several labels deep, such as a.b.example.com, without delegating b.example.com?Yes. A zone is cut only where the parent publishes an `NS` RRset for a child. Without that, `a.b.example.com` is ordinary authoritative data of `example.com`, and `b.example.com` may own no records at all (an empty non-terminal). Depth in the tree and zone boundaries are independent.
- Why do the DNS specifications insist on at least two authoritative servers per zone?RFC 1034 §4.1 requires every zone to be available on at least two servers so that one host or link failing does not make the whole zone unreachable. That is why primaries and secondaries exist: the secondaries hold copies obtained by zone transfer and answer authoritatively in their own right.
saying these in an interview costs you the question
- A zone and a domain are the same thing under two names.
- Delegating dev.example.com removes it from the example.com domain.
- The NS records at a cut are authoritative data of the parent zone.
- Any server that returns a record is authoritative for that record.
- A zone can only hold names one label below its apex.