1. What Delegation Actually Is¶

Delegation is the mechanism that makes DNS a distributed system rather than a single centrally-managed database. When you register example.com, the .com registry doesn't store your A records, your MX records, or anything about your actual infrastructure — it stores exactly one thing about example.com: who to ask instead. That "who to ask instead" pointer is delegation, expressed as NS records in the parent zone.

This is the single most important distinction in this whole topic, and the one most often glossed over: a domain name and a zone are not the same thing. example.com is a name. The zone containing its records might be hosted entirely as one unit, or split into multiple zones (example.com itself, plus a separately-delegated dev.example.com) each administered — potentially by entirely different people, teams, or companies — independently.

2. How Delegation Is Expressed¶

Two record types, in two different zones, working together:

In the parent zone (.com's servers, conceptually):

example.com.    IN  NS  ns1.examplehost.net.
example.com.    IN  NS  ns2.examplehost.net.

In the child zone itself (served by ns1/ns2.examplehost.net):

example.com.    IN  SOA ns1.examplehost.net. admin.examplehost.net. ( ... )
example.com.    IN  NS  ns1.examplehost.net.
example.com.    IN  NS  ns2.examplehost.net.
www             IN  A   192.0.2.10

Note the NS records appear in both places — once at the parent (the actual delegation, telling resolvers where to go next) and once inside the child zone itself (asserting, from the zone's own authoritative data, who its name servers are). These two copies can, in principle, drift out of sync — a lame delegation (§6) is exactly this failure mode.

3. Glue Records: Solving the Chicken-and-Egg Problem¶

A subtlety arises when a zone's own name servers have names inside that same zone — extremely common (ns1.example.com serving example.com). A resolver following the delegation is told "ask ns1.example.com" but doesn't yet have ns1.example.com's IP address — and getting that address normally requires... asking example.com's name servers, which is the very thing it's trying to reach. This circular dependency is broken by glue records: the parent zone directly includes A/AAAA records for the delegated name servers, alongside the NS records, so the resolver never needs to ask the child zone to find its own servers.

example.com.          IN  NS  ns1.example.com.
example.com.          IN  NS  ns2.example.com.
ns1.example.com.      IN  A   192.0.2.1     ; glue
ns2.example.com.      IN  A   192.0.2.2     ; glue

Glue is required specifically when a delegated name server's name falls inside or below the zone being delegated (an "in-bailiwick" name server). If example.com's name servers are instead named something outside the zone entirely (ns1.dnsprovider.net), no glue is needed — that name resolves independently through its own, unrelated delegation chain, no circularity involved.

A common practical consequence: glue records live at the registrar, not in your own zone file, and are configured separately from ordinary DNS records — through the registrar's "custom nameserver" or "glue record" management screen, not through whatever DNS provider hosts the zone's actual content. Forgetting this is a frequent source of "I updated my zone file but the delegation still points at the old IP" confusion.

4. Multi-Level Delegation¶

Delegation nests arbitrarily deep. dev.example.com can be delegated as its own zone from within example.com, exactly the same way example.com is delegated from .com:

; inside example.com's zone
dev.example.com.    IN  NS  ns1.devteam-dns.net.
dev.example.com.    IN  NS  ns2.devteam-dns.net.

This is how organizations hand a subdomain to a different team, a different vendor (e.g., a SaaS product managing app.yourcompany.com entirely on your behalf), or a different DNS provider without touching the parent zone's actual record data at all — the parent zone owner only needs to add this one NS delegation, and everything under dev.example.com becomes the delegate's sole responsibility from that point down.

Contrast this with simply adding records for dev.example.com directly inside example.com's own zone file (no separate delegation) — functionally valid, and simpler for a subdomain that doesn't need independent administration, but it means every change still goes through whoever controls example.com's zone. The decision of whether to delegate a subdomain versus just adding records for it in the existing zone is really a decision about who needs independent administrative control, not a technical requirement.

5. Delegation vs. CNAME: A Common Confusion¶

Delegating dev.example.com to different name servers is not the same thing as pointing dev.example.com at another name via CNAME:

Delegating is the right tool when an entire subdomain needs to be independently managed (different team, different provider, potentially many records under it). CNAME is the right tool for aliasing one specific name to another's existing records without handing off any administrative authority.

6. Lame Delegations¶

A lame delegation is when the parent zone's NS records point at servers that are not actually, or no longer, authoritative for that zone — a classic operational rot that accumulates silently:

• A provider migration happened, and the old NS records at the parent were never updated.
• A server listed as authoritative was decommissioned, repurposed, or had the zone removed from its config.
• The delegated server exists and answers, but for a different zone (name reused, or a copy-paste error in someone else's config).

Lame delegations cause intermittent, confusing resolution failures rather than a clean, consistent error — some resolvers might have a cached (stale but still "working") answer from before the lameness set in, while fresh lookups against the actual delegated servers fail or return unexpected data. Detection is straightforward once you think to check it:

dig NS example.com                     # what the parent says the delegation is
dig @<each-listed-ns> example.com SOA  # does each one actually answer authoritatively?

Any listed server that fails to answer, or answers as if it doesn't actually host the zone, indicates lameness — a periodic, scriptable check worth running against any zone's delegation as basic hygiene, since these tend to go unnoticed until something visibly breaks.

7. Hidden Primary (Hidden Master) Architecture¶

A widely used pattern for delegation and redundancy together: the actual editable primary/master server for a zone is not listed in the delegation at all — only a set of public-facing secondaries are. The primary lives on a private, unadvertised address, pushing zone transfers (AXFR/IXFR, or a provider-specific push mechanism) to the public secondaries, which are the only servers the delegation's NS records — and glue — ever point at.

Benefits: the primary, which holds the actual editable zone data and is the single point that would be catastrophic to compromise, is never directly reachable or even discoverable from outside; all public query load and any attack surface lands on expendable, easily-replaced secondaries instead. This is the architecture referenced in DNS-architect job descriptions as "hidden master" — it's a delegation-and-redundancy pattern, not a special record type or protocol feature.

8. Delegation Checklist for a New Subdomain¶

1. Decide whether this subdomain genuinely needs independent administration (different team/vendor) — if not, just add records in the existing zone instead.
2. Stand up the new zone at its chosen name servers, with a correct SOA and NS records matching what will be delegated.
3. Add the delegating NS records in the parent zone.
4. If the new name servers' names fall inside the zone being delegated, add glue records at the registrar, not just in either zone file.
5. Verify with dig +trace for a name inside the new zone — confirm the trace actually follows the delegation down to the new servers and gets an authoritative answer, not a lame or missing response.
6. Periodically re-verify (see §6) — delegation correctness degrades silently over time as infrastructure changes.

9. Reference Links¶

• RFC 1034 §4.2 (delegation and glue, in the original DNS specification)
• RFC 2181 §5 (clarifications on zone/authority definitions)