DNS Delegation: How Zones & Nameserver Chains Work

Updated February 10, 2026

DNS doesn't store all records in one giant database. Instead, it divides the namespace into zones, each managed by its own set of nameservers. The process of handing authority from one zone to another is called delegation — and it's the mechanism that makes DNS scalable, distributed, and resilient.

This guide explains how delegation works, what happens at each level, and how to trace the chain from root to your domain.

The DNS Hierarchy

The DNS namespace is a tree. At the top is the root zone (.), which delegates to top-level domains (TLDs) like .com, .org, and .app. Each TLD delegates to individual domains, and domains can further delegate subdomains.

.                          ← Root zone
├── com.                   ← TLD (delegated by root)
│   ├── example.com.       ← Domain (delegated by .com)
│   │   └── api.example.com.  ← Subdomain (may or may not be delegated)
│   └── another.com.
├── app.
│   └── mysite.app.
└── org.

Each arrow represents a delegation — the parent zone publishes NS records pointing to the child zone's nameservers.

What Is a Zone?

A zone is a contiguous portion of the DNS namespace under a single administrative authority. A zone starts at a delegation point and includes all names below it until another delegation occurs.

Key distinction: a zone is not the same as a domain. The domain example.com and the zone example.com often overlap, but if api.example.com is delegated to separate nameservers, it becomes its own zone — even though it's still part of the example.com domain.

How Delegation Works

When a parent zone delegates authority to a child zone, it does two things:

1. NS Records at the Parent

The parent publishes NS records in its zone file that name the child zone's nameservers:

; In the .com zone file:
example.com.    NS    ns1.exampledns.com.
example.com.    NS    ns2.exampledns.com.

These NS records tell resolvers: "I don't have records for example.com — ask these servers instead."

2. Glue Records (When Needed)

If a nameserver's name is inside the zone it serves, the parent must also include glue records — A/AAAA records for the nameserver — to break the circular dependency.

; Glue records in the .com zone (needed because ns1 is under example.com):
example.com.       NS    ns1.example.com.
ns1.example.com.   A     203.0.113.10

Without glue, a resolver trying to look up ns1.example.com would need to query the nameservers for example.com, which are... ns1.example.com. Circular.

The Delegation Chain in Action

Here's what happens when a recursive resolver needs to look up thegoldpass.app A:

Step 1: Root Zone

The resolver asks a root server: "What are the nameservers for thegoldpass.app?"

The root doesn't know about thegoldpass.app directly, but it knows who handles .app:

app.    NS    ns-tld1.charlestonroadregistry.com.
app.    NS    ns-tld2.charlestonroadregistry.com.

Step 2: TLD Zone (.app)

The resolver asks .app's nameservers: "What are the nameservers for thegoldpass.app?"

thegoldpass.app.    NS    ns1.example.com.
thegoldpass.app.    NS    ns2.example.com.

Step 3: Domain Zone (thegoldpass.app)

The resolver asks the domain's nameservers for the actual A record:

thegoldpass.app.    A    93.184.216.34

The resolver now has the answer and caches it according to the record's TTL.

DNSSEC and Delegation

Delegation doesn't just pass authority — it can also pass cryptographic trust. DNSSEC uses two record types to link the chain:

• DNSKEY — The zone's public signing keys, published in the zone itself.
• DS (Delegation Signer) — A hash of the child's key, published in the parent zone. This is the trust link.

When a parent zone includes a DS record for a child, it's saying: "I vouch for this child's signing key." The resolver verifies the chain from the root (whose keys are pre-trusted) through each DS → DNSKEY link down to the target domain.

.                DNSKEY → trust anchor (pre-configured)
    ↓ DS record
app.             DNSKEY → verified by root's DS
    ↓ DS record
thegoldpass.app. DNSKEY → verified by app.'s DS

If any link is missing (no DS at the parent) or broken (DS doesn't match DNSKEY), the chain fails. DNS Kit's delegation trace checks every link and reports the DNSSEC status at each zone level. For a deeper dive into DNSSEC, see our DNS flags & DNSSEC guide.

Subdomain Delegation

By default, subdomains are part of the parent domain's zone — api.example.com is served by the same nameservers as example.com. But you can delegate a subdomain to separate nameservers by adding NS records:

; In the example.com zone:
api.example.com.    NS    ns1.api-provider.com.
api.example.com.    NS    ns2.api-provider.com.

This creates a new zone for api.example.com with its own set of authoritative servers. The parent zone (example.com) no longer holds records for api.example.com — all queries are referred to the delegated servers.

Common reasons to delegate subdomains:

• Different teams manage different subdomains
• A subdomain is hosted by a third-party service with its own DNS
• Separate DNSSEC signing requirements
• Isolating DNS failures to a single subdomain

Diagnosing Delegation Problems

Lame Delegation

A lame delegation occurs when a parent zone's NS records point to a nameserver that doesn't actually serve the zone. The nameserver exists but responds with REFUSED or SERVFAIL instead of an authoritative answer.

Common causes:

• Changed DNS providers but didn't update NS records at the registrar
• Nameserver decommissioned without updating the parent zone
• Typo in the nameserver hostname

Missing Glue Records

If your nameservers are within your own domain and glue records are missing or incorrect, resolution fails completely — resolvers can't resolve the nameserver address because the zone they'd need to query is the one they're trying to find nameservers for.

Broken DNSSEC Chain

A DS record in the parent that doesn't match the child's DNSKEY causes DNSSEC validation to fail. This typically results in SERVFAIL responses from validating resolvers, even though the actual DNS data is correct.

How to Check Your Delegation

Method 1: DNS Kit Delegation Trace

The easiest way is to use DNS Kit's Delegation Trace mode. It walks the full chain from root to your domain, showing nameservers, DNSSEC status, and individual query results at every zone level.

Method 2: dig +trace

The dig command can trace the delegation chain from the command line:

dig example.com +trace

This follows referrals from root → TLD → domain, showing the NS records returned at each step. Add +dnssec to include DNSSEC records in the output.

Method 3: Check NS Records Manually

Query each level separately to inspect the delegation:

# Check what the TLD says about your domain
dig @a.gtld-servers.net example.com NS

# Check what your nameservers respond with
dig @ns1.your-provider.com example.com SOA

If the TLD's NS records don't match what your nameservers expect, delegation is misconfigured.

Summary

DNS delegation is the backbone of how the internet's naming system scales. Every domain lookup traverses a chain of delegations — from root to TLD to domain to (optionally) subdomain — with each zone handing off authority to the next through NS records. DNSSEC extends this chain with cryptographic trust via DS and DNSKEY records.

Understanding delegation helps you:

• Diagnose why a domain isn't resolving
• Verify nameserver changes took effect
• Troubleshoot DNSSEC validation failures
• Plan subdomain delegation for complex architectures

For related topics, see our guides on DNS record types, DNS propagation, and DNSSEC validation.