fundamentals

Zones and Delegation

How the DNS namespace is divided into administrative units

When one team cannot manage everything

Imagine your company, bigcorp.com, has grown from a handful of engineers to a thousand-person organization with teams spread across four continents. The platform team manages api.bigcorp.com. The marketing team runs www.bigcorp.com. The internal tools team needs internal.bigcorp.com. And each team wants to manage their own DNS records — creating subdomains, updating IP addresses, deploying services — without filing tickets with a central operations team and waiting days for changes.

This is exactly the problem DNS zones and delegation solve. Instead of one massive zone file controlled by one team, you split the namespace into independent zones, each managed by its own set of authoritative name servers. The platform team gets full control over the api.bigcorp.com zone. The internal tools team controls internal.bigcorp.com. Changes happen independently, instantly, without coordination.

This is not a workaround. It is how DNS was designed to work from the beginning. The entire internet — from the root zone down to every subdomain — is structured as a hierarchy of delegated zones.

Zone vs. domain: the distinction that matters

These two terms are often used interchangeably, but they mean different things.

A domain is a node in the DNS tree and everything beneath it. The domain example.com includes www.example.com, mail.example.com, api.example.com, and any other names under example.com.

A zone is a contiguous portion of the namespace managed by a specific set of authoritative name servers. A zone starts at a node and extends downward — but it stops wherever delegation occurs.

example.com zone
  |
  |-- www.example.com          (A record -- in this zone)
  |-- mail.example.com         (A record -- in this zone)
  |-- example.com              (MX, TXT, SOA, NS -- in this zone)
  |
  |-- [delegation point]
  |     |
  |     v
  |   api.example.com zone     (separate zone, different name servers)
  |     |-- api.example.com    (A record -- in delegated zone)
  |     |-- v2.api.example.com (A record -- in delegated zone)

In this example, example.com the domain includes everything — www, mail, api, and v2.api. But example.com the zone does not include api.example.com or anything below it, because that portion has been delegated to a separate zone with its own authoritative servers.

The key insight: a domain can span multiple zones, but a zone always has exactly one set of authoritative servers.

Zone files: the source of truth

A zone file is a plain text file containing all the DNS records for a zone. It is the authoritative source of truth — the data that name servers load and serve to resolvers.

Here is a complete, annotated zone file:

$ORIGIN example.com.
$TTL 86400

; SOA Record — required, must be first
@   IN  SOA ns1.example.com. admin.example.com. (
            2025021301  ; Serial (YYYYMMDDNN format)
            3600        ; Refresh (1 hour)
            900         ; Retry (15 minutes)
            1209600     ; Expire (2 weeks)
            86400       ; Minimum / Negative Cache TTL (1 day)
        )

; Name Servers
@       IN  NS  ns1.example.com.
@       IN  NS  ns2.example.com.

; A Records
@       IN  A       93.184.216.34
www     IN  A       93.184.216.34
mail    IN  A       93.184.216.50

; AAAA Record
@       IN  AAAA    2606:2800:220:1:248:1893:25c8:1946

; Mail
@       IN  MX  10  mail.example.com.
@       IN  MX  20  backup-mail.example.com.

; TXT Records
@       IN  TXT     "v=spf1 include:_spf.google.com ~all"

; CNAME
blog    IN  CNAME   example.tumblr.com.

; Delegation (creates a child zone)
api     IN  NS      ns1.api.example.com.
api     IN  NS      ns2.api.example.com.

; Glue records (required because ns1.api is within the delegated zone)
ns1.api IN  A       198.51.100.10
ns2.api IN  A       198.51.100.20

; CAA (certificate authority authorization)
@       IN  CAA 0 issue "letsencrypt.org"

The `$ORIGIN` directive

$ORIGIN example.com. sets the default suffix for any name in the file that does not end with a dot. When you write:

www     IN  A   93.184.216.34

The name www is not fully qualified (no trailing dot), so the zone file software appends $ORIGIN to produce www.example.com.. This is why the trailing dot matters so much in DNS — www.example.com. (with dot) is an absolute FQDN, while www.example.com (without dot) would be interpreted as www.example.com.example.com. inside a zone file with $ORIGIN example.com..

This is one of the most common zone file mistakes: forgetting the trailing dot on a CNAME target or MX target, which causes the origin to be appended and produces a completely wrong name.

The `$TTL` directive

$TTL 86400 sets the default TTL for all records in the zone that do not specify their own TTL. This value (86,400 seconds = 24 hours) is applied to every record unless explicitly overridden. See Caching and TTL for guidance on choosing TTL values.

The `@` symbol

In zone files, @ is shorthand for the zone origin — whatever $ORIGIN is set to. So @ IN A 93.184.216.34 means example.com. IN A 93.184.216.34.

How delegation works

Delegation is the mechanism that splits the DNS tree into separate zones. It works through NS records in the parent zone that point to the child zone’s authoritative servers.

The delegation chain

Every domain you resolve passes through a chain of delegations:

Root Zone (.)
  |
  | NS records delegate .com to Verisign's TLD servers
  | (a.gtld-servers.net through m.gtld-servers.net)
  v
.com TLD Zone
  |
  | NS records delegate example.com to its authoritative servers
  | (ns1.example.com, ns2.example.com)
  v
example.com Zone
  |
  | NS records delegate api.example.com to its own servers
  | (ns1.api.example.com, ns2.api.example.com)
  v
api.example.com Zone

At each delegation point, the parent zone contains two things:

NS records pointing to the child zone’s name servers
Glue records (when necessary) providing the IP addresses of those name servers

Glue records: breaking circular dependencies

Consider this scenario: the .com TLD zone delegates example.com to ns1.example.com. A resolver needs to reach ns1.example.com to look up records for example.com — but to find the IP address of ns1.example.com, it would need to query the example.com zone, which it cannot reach yet. This is a circular dependency.

Glue records break the cycle. The parent zone (.com) includes A records for ns1.example.com directly, providing the IP address alongside the NS delegation. The resolver can use this “glue” to reach the authoritative server without a separate lookup.

Glue records are required in one scenario:

The name server’s hostname is within the zone being delegated (in-bailiwick). Example: ns1.example.com is authoritative for example.com — the name server name is inside the zone it serves.

Glue records are not needed when:

The name server’s hostname is outside the delegated zone (out-of-bailiwick). Example: using ns1.cloudflare.com as the authoritative server for example.com — the resolver can look up ns1.cloudflare.com independently through the cloudflare.com zone.

In-bailiwick vs. out-of-bailiwick

This terminology comes up frequently in DNS operations:

Term	Meaning	Example for `example.com`
In-bailiwick	Name server hostname is within the delegated zone	`ns1.example.com`
Out-of-bailiwick	Name server hostname is in a different zone	`ns1.cloudflare.com`
Sibling glue	Name server is in a sibling zone under the same parent	`ns1.example.net` (when delegated from `.net`)

Using out-of-bailiwick name servers (like those from a managed DNS provider) avoids the need for glue records entirely and simplifies the delegation setup.

Zone types

DNS servers can host zones in different roles:

Zone Type	Description	Records Editable?
Primary (Master)	The authoritative source of truth for the zone	Yes — this is where changes are made
Secondary (Slave)	A read-only copy obtained via zone transfer from the primary	No — updated only through transfers
Stub	Contains only NS records and glue for a delegated zone	No — only tracks name server changes
Forward	Redirects queries for a zone to designated resolvers	N/A — does not store zone data

Most production DNS setups have one primary and one or more secondary servers. The secondary servers provide redundancy (if the primary goes down, secondaries keep answering) and load distribution (queries are spread across all authoritative servers).

Zone transfers: keeping secondaries in sync

Zone transfers replicate DNS data from a primary server to its secondary servers. There are two types:

Transfer Type	Protocol	Description
AXFR	TCP	Full zone transfer — sends the entire zone. Used for initial synchronization or when incremental data is unavailable.
IXFR	TCP/UDP	Incremental zone transfer — sends only the changes since a given serial number. Far more efficient for large zones with small updates.

How zone transfers work

The secondary server checks the primary’s SOA record at intervals defined by the Refresh timer (e.g., every 3,600 seconds).
It compares the SOA serial number with its own copy.
If the primary’s serial is higher, a zone transfer is initiated — IXFR if the secondary supports it and the primary has the incremental data, otherwise AXFR.
If the primary is unreachable, the secondary retries at the Retry interval (e.g., every 900 seconds).
If the primary remains unreachable beyond the Expire timer (e.g., 1,209,600 seconds = 2 weeks), the secondary stops answering queries for that zone — it considers its data too stale to serve.

NOTIFY: faster propagation

The refresh-based polling approach has a built-in delay — up to one full refresh interval before secondaries notice a change. RFC 1996 introduced DNS NOTIFY, which allows the primary to immediately inform secondaries when a zone changes. On receiving a NOTIFY message, the secondary initiates a zone transfer immediately rather than waiting for the next refresh cycle.

Most modern DNS software enables NOTIFY by default.

Securing zone transfers

Zone transfers expose the complete contents of a zone, which is sensitive information. Unsecured AXFR allows anyone to enumerate all records in a zone. Best practices include:

IP-based ACLs: Restrict zone transfers to specific secondary server IP addresses
TSIG (Transaction Signatures): Authenticate zone transfer requests using shared-secret HMAC keys (RFC 2845)
TLS: Some modern implementations support zone transfers over TLS for encryption

The global hierarchy in numbers

The delegation model scales from the root zone to hundreds of millions of domains:

Level	Count	Description
Root zone	1 zone, 13 logical servers, ~1,954 instances	Managed by IANA; operated by 12 independent organizations
TLD zones	~1,593 TLDs	Includes gTLDs (`.com`, `.org`, `.net`), ccTLDs (`.uk`, `.de`, `.jp`), and new gTLDs (`.xyz`, `.app`, `.dev`)
Second-level domains	~378.5 million registered	The domains people and organizations register
Subdomains	Effectively unlimited	Created at the discretion of domain owners

Every single one of these levels uses the same delegation mechanism: NS records in the parent zone pointing to the child zone’s authoritative servers. The same protocol that delegates .com from the root zone is the same protocol that delegates api.example.com from example.com. This uniformity is what allows DNS to scale to the size of the internet.

Common delegation mistakes

Lame delegation. The parent zone has NS records pointing to a server that does not actually host the zone. The server either does not respond or returns REFUSED/SERVFAIL. This breaks resolution for the entire zone.

Missing glue records. Using in-bailiwick name servers without providing glue records in the parent zone creates a circular dependency that prevents resolution.

Stale glue. Glue records in the parent zone have the old IP address after you have moved your name servers. Since glue is managed by the parent (your registrar), you need to update it there — not just in your zone file.

Serial number not incremented. Editing the zone file without incrementing the SOA serial means secondaries never pick up the change. They compare serial numbers, and if the number has not increased, they assume nothing changed.

TTL too long on NS records. If your NS records have a 24-hour TTL and you need to migrate DNS providers, resolvers will continue querying the old servers for up to 24 hours. Lower the NS record TTL well in advance of any provider migration.

Next steps

Zone files contain records, and those records have TTL values that control how long they are cached at each layer of the DNS infrastructure. Understanding caching and TTL is essential for managing DNS changes, migrations, and performance tuning.

Related Resources

What Is Dns

Record Types