Loading learning content...
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.
By the end of this page, you will understand: (1) The concept and purpose of DNS delegation, (2) How NS records implement delegation, (3) The critical role of glue records, (4) Subdomain delegation patterns, (5) The difference between delegation and zone cuts, (6) Common delegation problems and debugging techniques, and (7) Best practices for reliable delegation configuration.
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:
Delegation solves these problems by distributing authority:
Each entity manages only their portion of the namespace.
The delegation chain:
Every fully qualified domain name (FQDN) represents a chain of delegations:
| Domain | Delegation Chain |
|---|---|
| www.google.com. | Root → .com (Verisign) → google.com (Google) → www (Google authoritative) |
| cloud.google.com. | Root → .com → google.com → cloud.google.com (possibly delegated further) |
| www.bbc.co.uk. | Root → .uk (Nominet) → co.uk → bbc.co.uk (BBC) → www |
| ns1.example.org. | Root → .org (PIR) → example.org (owner) → ns1 |
At each step, the parent zone contains NS records pointing to the child zone's nameservers. This chain is traversed during resolution.
Not every subdomain is delegated. If you own example.com and create www.example.com, that's just an A record in your zone—no delegation occurs. Delegation happens when you say 'subdomain.example.com is managed by different nameservers.' The key indicator is NS records for the subdomain in the parent zone.
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:
1234567891011121314
; In the .com zone file (Verisign); This is the DELEGATION - parent zone pointing to child's nameservers ; Delegation NS records for google.comgoogle.com. 172800 IN NS ns1.google.com.google.com. 172800 IN NS ns2.google.com.google.com. 172800 IN NS ns3.google.com.google.com. 172800 IN NS ns4.google.com. ; Glue records (addresses of nameservers within delegated zone)ns1.google.com. 172800 IN A 216.239.32.10ns2.google.com. 172800 IN A 216.239.34.10ns3.google.com. 172800 IN A 216.239.36.10ns4.google.com. 172800 IN A 216.239.38.10NS records at the child (zone apex):
The child zone also contains NS records at its apex, confirming its own authoritative servers:
1234567891011121314151617181920
; In the google.com zone file (Google); This is the AUTHORITATIVE declaration - zone stating its own nameservers $ORIGIN google.com. ; Zone apex NS records@ 172800 IN NS ns1.google.com.@ 172800 IN NS ns2.google.com.@ 172800 IN NS ns3.google.com.@ 172800 IN NS ns4.google.com. ; A records for nameservers (same as parent's glue)ns1 172800 IN A 216.239.32.10ns2 172800 IN A 216.239.34.10ns3 172800 IN A 216.239.36.10ns4 172800 IN A 216.239.38.10 ; Actual zone content@ 300 IN A 142.250.185.206www 300 IN A 142.250.185.206The two copies of NS records must match:
Notice that NS records exist in both zones:
These should be consistent. Mismatches cause resolution problems:
| Scenario | Problem |
|---|---|
| Parent has NS that child doesn't | Resolver may query non-authoritative server |
| Child has NS that parent doesn't | Resolver never learns about additional servers |
| Different addresses in glue vs. child | Split-brain resolution; inconsistent results |
When a resolver follows referrals, it uses the NS records from the parent zone (the delegation). The child zone's NS records are only used for caching once the resolver reaches the child. If the parent's NS records are wrong, resolution fails—even if the child's NS records are correct. Always ensure registrar configuration (which populates the parent) matches your actual nameservers.
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:
www.google.com, the resolver asks the .com TLD servers.com says: "Ask ns1.google.com for google.com"ns1.google.com, the resolver needs its IP addressns1.google.com, the resolver asks the .com TLD servers.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:
| Nameserver Name | Example | Glue Required? | Reason |
|---|---|---|---|
| Within delegated zone (in-bailiwick) | ns1.google.com for google.com | Required | Cannot resolve without glue |
| Sibling domain (same parent) | ns.example.com for google.com | Optional (often included) | Can be resolved independently, but glue optimizes |
| Different TLD entirely | ns.amazonaWS.com for google.com | Not applicable | Resolver resolves .com delegation first |
| Different parent | ns.cloudflare.net for example.com | Not needed | ns.cloudflare.net resolved via .net, not .com |
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.
If glue records in the parent don't match the actual A/AAAA records in the child zone, resolvers may use stale or incorrect IP addresses. Always update glue records at your registrar when nameserver IPs change. Some registrars call these 'host records' or 'nameserver records.'
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.comexample.com answer queries for sub.example.comIf delegated:
example.com zone contains only NS records for sub.example.comsub.example.comsub.example.com1234567891011121314151617181920212223242526272829303132
; ===== example.com ZONE (Parent) =====$ORIGIN example.com. @ IN SOA ns1.example.com. admin.example.com. (...)@ IN NS ns1.example.com.@ IN NS ns2.example.com.@ IN A 93.184.216.34www IN A 93.184.216.34mail IN A 93.184.216.50 ; ZONE CUT - delegation to sub.example.com; Only NS and glue records for delegated subzonesub IN NS ns1.sub.example.com.sub IN NS ns2.sub.example.com.ns1.sub IN A 198.51.100.1 ; Gluens2.sub IN A 198.51.100.2 ; Glue ; Parent zone does NOT contain:; - A records for sub.example.com; - Any records for *.sub.example.com; Those belong to the delegated zone ; ===== sub.example.com ZONE (Child) =====$ORIGIN sub.example.com. @ IN SOA ns1.sub.example.com. admin.example.com. (...)@ IN NS ns1.sub.example.com.@ IN NS ns2.sub.example.com.ns1 IN A 198.51.100.1ns2 IN A 198.51.100.2@ IN A 198.51.100.10 ; A record for sub.example.comwww IN A 198.51.100.11 ; A record for www.sub.example.comWhat the parent zone can and cannot contain for delegated zones:
| Record Type | Allowed in Parent? | Notes |
|---|---|---|
| NS for child apex | Required | The delegation itself |
| A/AAAA for in-bailiwick NS | Required (glue) | Enables resolution |
| DS for DNSSEC | Allowed | Links child's DNSSEC to parent |
| A/AAAA for child apex | No | Child zone is authoritative |
| MX, TXT, etc. for child | No | Child zone is authoritative |
| Any records for names under child | No | Child zone is authoritative |
If you have records at a.b.c.example.com but nothing at b.c.example.com, the name b.c.example.com becomes an 'empty non-terminal'—it exists (is not NXDOMAIN) but has no records (NODATA for any query type). This is valid and common, but can confuse administrators expecting NXDOMAIN.
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:
123456789101112131415
; SaaS email providermail.example.com. IN NS ns1.emailprovider.com.mail.example.com. IN NS ns2.emailprovider.com. ; Cloud infrastructure cloud.example.com. IN NS ns-1234.awsdns-12.org.cloud.example.com. IN NS ns-5678.awsdns-34.co.uk. ; CDN content deliverycdn.example.com. IN NS ns1.cdnprovider.net.cdn.example.com. IN NS ns2.cdnprovider.net. ; Kubernetes/container platformk8s.example.com. IN NS ns1.k8s-internal.example.com.k8s.example.com. IN NS ns2.k8s-internal.example.com.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
If you just need to point a subdomain to external servers, CNAME is often simpler than delegation. Use CNAME when: the external service provides a target hostname (e.g., yoursite.cdn.net). Use delegation when: you need the subdomain to have its own zone with multiple records, or the external service requires NS delegation (like some cloud providers for their DNS services).
Delegation problems are among the most common DNS issues. Here's how to diagnose and verify delegations.
Essential diagnostic commands:
1234567891011121314151617181920212223242526272829
# 1. Check delegation at parent (TLD level)# Query .com servers for example.com NS records$ dig @a.gtld-servers.net example.com NS; Shows what .com has delegated # 2. Check authoritative NS at child$ dig @ns1.example.com example.com NS; Shows what the zone claims as its nameservers # 3. Full trace shows each delegation step$ dig +trace example.com A; Watch for referrals at each level # 4. Check for glue records$ dig @a.gtld-servers.net example.com NS +additional; +additional shows glue records in response # 5. Verify nameserver responds authoritatively$ dig @ns1.example.com example.com SOA; AA flag should be set in response # 6. Check subdomain delegation$ dig @ns1.example.com sub.example.com NS; Returns NS records if delegated, or NOERROR/NXDOMAIN otherwise # 7. Compare parent and child NS records$ dig +short @a.gtld-servers.net example.com NS$ dig +short @ns1.example.com example.com NS# These should match!Common delegation problems and solutions:
| Symptom | Likely Cause | Verification | Solution |
|---|---|---|---|
| SERVFAIL for domain | Nameserver unreachable or not configured | dig @ns1 domain.com SOA | Configure nameserver; check firewall |
| Resolution inconsistent | Parent/child NS mismatch | Compare parent and child NS records | Update registrar to match zone |
| Subdomain doesn't resolve | Missing delegation or wrong NS | dig @parent subdomain NS | Add NS records to parent zone |
| Wrong IP returned | Stale glue records | Compare parent glue to actual NS IP | Update glue at registrar |
| NXDOMAIN for delegated subdomain | Delegation exists but child zone missing | Test child nameservers directly | Configure zone on delegated servers |
| Only some resolvers work | Partial delegation (one NS works, others don't) | Query each NS individually | Ensure all listed NS are functioning |
| Lame delegation | NS listed but not authoritative for zone | dig @ns domain.com (check AA flag) | Configure zone on server or remove NS |
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:
Lame delegations cause resolution delays (resolver tries lame server, times out, tries another) and can cause failures if all listed servers are lame.
The NS records in your parent zone come from your registrar configuration, NOT from your zone file. Editing NS records in your zone file doesn't change what the parent (.com, .org, etc.) serves. You must update your registrar's nameserver settings. Many administrators make this mistake and wonder why their NS changes don't propagate.
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:
dig @new-ns zone.com SOAMigration:
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
| Scenario | Recommended NS Count | Notes |
|---|---|---|
| Small personal domain | 2 | Minimum viable; consider managed DNS |
| Business website | 2-4 | Geographic distribution recommended |
| Enterprise domain | 4-6 | Multi-provider for resilience |
| Critical infrastructure | 6+ | Multi-provider, multi-region, Anycast |
| TLD | 6-13 | Extensive Anycast; 13 is protocol maximum per response |
While there's no protocol maximum on nameservers, practical limits exist. The 512-byte UDP response limit (now 1232 with EDNS) constrains how many NS records and glue fit in a single response. Exceeding ~13 nameservers may cause truncation and TCP fallback. Most domains need far fewer; TLDs use 13 maximum.
Delegation is the fundamental mechanism that enables DNS's distributed, hierarchical architecture. It transfers authority from parent zones to child zones, allowing independent management of namespace segments while maintaining a unified global system.
Module complete:
With this page, you've completed the DNS Hierarchy module. You now understand:
This hierarchical, delegated architecture is what makes DNS scalable to billions of domains while remaining fast, reliable, and distributed. The next module will explore DNS Records in depth—the actual data types that populate these zones.
Congratulations! You've completed the DNS Hierarchy module. You now have a comprehensive understanding of DNS's distributed architecture—from root servers at the apex through TLD and authoritative servers to resolvers serving end users, all connected through the delegation mechanism. This foundation prepares you to understand DNS operations, records, resolution, caching, and security in subsequent modules.