Delegation

The DNS hierarchy—root servers, TLD servers, authoritative servers—wouldn't function without delegation. Delegation is the mechanism by which authority for a portion of the DNS namespace is transferred from a parent zone to a child zone.

When Verisign's root servers say "for .com, ask the .com TLD servers," that's delegation. When the .com TLD servers say "for google.com, ask Google's nameservers," that's delegation. When Google's nameservers say "for cloud.google.com, ask these other servers," that's delegation again.

Delegation is the glue that binds the hierarchy together, enabling billions of domains to be independently managed while remaining part of a unified namespace.

Delegation is the process by which a parent zone transfers authority for a child zone to different nameservers. It's a formal statement: "I (the parent) am not authoritative for this subset of my namespace. These other servers are."

Why delegation exists:

Imagine if the root servers had to store records for every domain on the Internet—hundreds of millions of domains, billions of individual records. It would be:

1. Impossible to scale — No server could handle the load or storage
2. Unmanageable — Every domain change would require root zone updates
3. Single point of failure — Root compromise means total DNS compromise
4. Politically unacceptable — No organization should control all domains

Delegation solves these problems by distributing authority:

• Root servers delegate to TLD operators
• TLD operators delegate to domain registrants
• Domain owners can delegate subdomains to other parties

Each entity manages only their portion of the namespace.

The delegation chain:

Every fully qualified domain name (FQDN) represents a chain of delegations:

At each step, the parent zone contains NS records pointing to the child zone's nameservers. This chain is traversed during resolution.

Delegation is implemented through NS (Name Server) records. An NS record specifies which nameservers are authoritative for a zone.

NS records at the parent (delegation point):

When a parent zone delegates a child zone, it includes NS records for the child:

NS records at the child (zone apex):

The child zone also contains NS records at its apex, confirming its own authoritative servers:

The two copies of NS records must match:

Notice that NS records exist in both zones:

1. Parent zone — The delegation (referral): "go ask these servers"
2. Child zone — The authoritative declaration: "we are the servers"

These should be consistent. Mismatches cause resolution problems:

Glue records are A/AAAA records in a parent zone that provide IP addresses for nameservers within a delegated child zone. They solve a fundamental circular dependency.

The chicken-and-egg problem:

Consider google.com with nameservers ns1.google.com and ns2.google.com:

1. To resolve www.google.com, the resolver asks the .com TLD servers
2. .com says: "Ask ns1.google.com for google.com"
3. But to contact ns1.google.com, the resolver needs its IP address
4. To resolve ns1.google.com, the resolver asks the .com TLD servers
5. .com says: "Ask ns1.google.com for google.com" — circular dependency!

The resolver can't contact the nameserver without knowing its IP, but it can't learn the IP without contacting the nameserver.

Glue records break the cycle:

The parent zone includes A/AAAA records for nameservers that are within the delegated zone:

; In .com zone (parent)
google.com.       172800  IN  NS  ns1.google.com.   ; Delegation
ns1.google.com.   172800  IN  A   216.239.32.10     ; Glue - IP included!

Now when the resolver receives the delegation, it also receives the glue record—the nameserver's IP address is bundled with the referral. No circular lookup needed.

When glue is required vs. optional:

Out-of-bailiwick nameservers:

If your nameservers are in a different domain, no glue is needed:

; example.com uses Cloudflare nameservers
example.com.      172800  IN  NS  ada.ns.cloudflare.com.
example.com.      172800  IN  NS  bob.ns.cloudflare.com.
; No glue needed - resolver can independently resolve cloudflare.com

The resolver resolves ada.ns.cloudflare.com via the .com → cloudflare.com delegation chain—a separate, non-circular path.

A zone cut is the boundary where delegation occurs—where authority transitions from parent zone to child zone. Understanding zone cuts clarifies what data belongs where.

The zone cut concept:

Consider the domain sub.example.com:

If NOT delegated:

• example.com zone contains all records for sub.example.com
• No zone cut exists
• The authoritative servers for example.com answer queries for sub.example.com

If delegated:

• example.com zone contains only NS records for sub.example.com
• A zone cut exists at sub.example.com
• Different authoritative servers answer queries for sub.example.com

What the parent zone can and cannot contain for delegated zones:

Organizations delegate subdomains for various operational reasons. Understanding common patterns helps you design and troubleshoot delegation structures.

Pattern 1: Departmental/Team Delegation

Large organizations delegate subdomains to different teams:

example.com.                →  Corporate IT manages
engineering.example.com.    →  Delegated to Engineering team's DNS
hr.example.com.             →  Delegated to HR systems
cloud.example.com.          →  Delegated to cloud provider (AWS, GCP)

Benefits: Teams control their own DNS; changes don't require central IT.

Pattern 2: Geographic Delegation

example.com.       →  Global corporate
us.example.com.    →  Delegated to US data center
eu.example.com.    →  Delegated to EU data center
apac.example.com.  →  Delegated to APAC data center

Benefits: Regional autonomy; local DNS for local users.

Pattern 3: External Service Delegation

Delegating subdomains to third-party providers:

Pattern 4: Reverse DNS Delegation

IP address owners delegate reverse DNS zones:

; ISP delegates reverse DNS to customer
; Customer has 192.0.2.0/24 (256 IPs)
2.0.192.in-addr.arpa.    IN  NS  ns1.customer.com.
2.0.192.in-addr.arpa.    IN  NS  ns2.customer.com.

; Customer manages their own PTR records
1.2.0.192.in-addr.arpa.  IN  PTR  server1.customer.com.
2.2.0.192.in-addr.arpa.  IN  PTR  server2.customer.com.

Pattern 5: Dynamic/Ephemeral Subdomains

Some systems dynamically create and delegate subdomains:

; Each customer gets a delegated subdomain
customer123.platform.example.com.  →  Delegated to customer's DNS
customer456.platform.example.com.  →  Delegated to customer's DNS

; Or delegated to automated internal DNS
dev-abc123.internal.example.com.   →  Dynamic developer environment

Delegation problems are among the most common DNS issues. Here's how to diagnose and verify delegations.

Essential diagnostic commands:

Common delegation problems and solutions:

Lame delegation — the most common problem:

A lame delegation occurs when a parent zone lists an NS record pointing to a server that isn't actually authoritative for the zone. The server either:

• Doesn't have the zone configured
• Returns SERVFAIL or REFUSED
• Returns referral instead of authoritative answer

Lame delegations cause resolution delays (resolver tries lame server, times out, tries another) and can cause failures if all listed servers are lame.

Reliable delegation requires careful configuration and ongoing maintenance. These best practices prevent common problems:

Nameserver requirements:

Migration best practices:

Changing nameservers is a sensitive operation. Follow this procedure:

Pre-Migration:

1. Lower TTL on NS records 24-48 hours in advance
2. Configure zone on new nameservers
3. Verify new nameservers respond correctly: dig @new-ns zone.com SOA
4. Verify DNSSEC chain if applicable

Migration: 5. Update registrar with new nameservers 6. Add new NS to zone file; keep old NS temporarily 7. Monitor with dig @old-ns and dig @new-ns

Post-Migration: 8. Wait for old TTL to expire (so caches update) 9. Remove old NS from zone file 10. Raise TTL back to normal values 11. Decommission old nameservers only after full propagation