DNS Fundamentals Introductory 4 min read

DNS Zones and Delegation

How the DNS namespace is divided into zones, how authority is delegated, and why zone boundaries shape control, caching, and failure behavior.

Updated August 22, 2026

DNS reads as one continuous hierarchy, but nobody operates it that way. The namespace is carved into zones, each run by whoever holds authority for it, and authority moves between operators through delegation.

Zones explain why DNS scales globally, why outages hit some names and spare their neighbors, and why control in DNS is absolute inside its boundaries and nonexistent outside them.


A zone is a unit of authority

A DNS zone is the portion of the namespace that a specific set of authoritative name servers answers for.

A zone always starts at a node in the label tree, but it doesn’t automatically include everything beneath that node. A zone ends where delegation begins. The zone example.com might contain example.com, www.example.com, and mail.example.com, yet not shop.example.com if that name has been delegated elsewhere.

The distinction to hold onto is that a label marks a position in the namespace, while a zone marks who answers questions there. Zones exist so responsibility can spread across organizations, teams, and providers with no central coordinator.

DNS zone delegation showing parent zone handing off authority to child zone
Figure 1: Zone delegation creates boundaries where authority is handed off from parent to child.
RFC reference
DNS zones and delegation are defined in RFC 1034, Sections 4.1 and 4.2.

How authority is handed off

Delegation is what splits the tree into zones, and it’s implemented with ordinary records: NS records in the parent zone naming the servers that are authoritative for the child. When those servers sit below the delegated name itself, the parent also publishes glue records (plain A or AAAA entries) so resolvers can reach them without a circular lookup.

example.com.        IN NS    ns1.example.com.
example.com.        IN NS    ns2.example.com.

ns1.example.com.    IN A     192.0.2.10
ns2.example.com.    IN A     192.0.2.11

Once the delegation exists, the parent stops answering authoritatively for anything below that point. It only refers resolvers onward, and resolvers treat the boundary as final.


Zone cuts are absolute

The boundary a delegation creates is called a zone cut, and nothing in DNS softens it. The parent can’t answer authoritatively for names below the delegated label, can’t override or partially manage them, and every subdomain under the delegated name is the child’s to manage or delegate further. Two zones can’t hold overlapping authority for the same name, and splitting a subtree without a further delegation doesn’t exist in the protocol.

Case example
An organization hosts example.com on its own authoritative servers. During a migration, a team adds NS records for shop.example.com pointing to a SaaS provider, intending only to move the storefront.

Shortly after, DNS changes made in the example.com zone stop affecting any names under shop.example.com. The issue isn't propagation or caching. Once the delegation exists, the parent zone no longer has authority below that label, even though both teams believe they're managing the same domain.

Why delegation works this way

Delegation is intentionally coarse. Resolvers make simple, cacheable decisions: find the closest enclosing zone cut, query that zone’s servers, cache the answers until their TTLs expire. Overlapping or partial authority would complicate caching, multiply query volume, and make failure behavior unpredictable. The rigidity is what lets DNS perform at global scale.

The tradeoff is inflexibility, and it can’t be configured away. It’s the design.


Zones, caching, and failure scope

Zones also draw the failure boundaries. When a zone’s authoritative servers become unreachable, every name in the zone is affected, while zones served by other infrastructure keep resolving. Cached answers mask the outage for a while, but as TTLs expire, resolvers must reach the delegated servers again, and the failure surfaces.

This is why DNS outages so often look selective. One domain or subdomain fails while everything around it resolves normally. Zone design is a reliability decision, not just an administrative convenience.


Zones say who answers, nothing more

A single zone can point at infrastructure spread across many networks and regions. Many zones can point at the same addresses. DNS doesn’t care. Zone boundaries define who answers DNS questions, not where services run or how traffic flows afterward.

That separation is one reason DNS has stayed stable while everything about how applications and networks are built has changed around it.


Summary

Zones and delegation are how one global namespace is shared safely by millions of independent operators: strict, non-overlapping grants of authority that caching and resolution can rely on. The same coarse boundaries that make DNS scale also decide its failure behavior, and they help explain why attackers find DNS attractive. Once you see the zone cuts, DNS behaviors that seemed arbitrary start to feel inevitable.