DNS delegation is a hierarchical mechanism that transfers authority for a subdomain to a separate set of authoritative name servers through NS records published in the parent zone, enabling the DNS namespace to scale by distributing management responsibility across organizations and teams. The process involves creating a child zone on target name servers, adding corresponding NS records in the parent zone, and optionally publishing glue records when a nameserver's hostname resides within the delegated subdomain. Poorly managed delegation is a common source of DNS failures—including lame delegations, mismatched NS record sets, missing glue, and broken DNSSEC chains—making regular audits and consistency monitoring essential to prevent intermittent outages and security risks.
How DNS delegation works
Delegation works by placing pointers in the parent zone that tell resolvers where the child zone's authoritative servers are. The child zone then answers for every name beneath the delegation point.
- Create the child zone: The delegated party sets up a zone for the subdomain, such as sales.example.com, on its own authoritative name servers and loads the records for that zone.
- Add NS records to the parent: The parent zone administrator adds NS records at the delegation point that name the child zone's authoritative servers.
- Add glue records if needed: If a name server's hostname sits inside the delegated subdomain, the parent also publishes address records for it, called glue, so resolvers can reach it without a circular lookup.
- Resolver follows the referral: When a resolver queries the parent's servers for a name in the subdomain, they return a referral containing the NS records instead of an answer.
- Child servers answer: The resolver queries one of the named servers, which responds authoritatively for the subdomain.
The parent does not hold the child's data beyond the NS and glue records, so the child can change its records freely. The NS records in the child zone should match those in the parent, or resolution can become inconsistent. If DNSSEC is used, the parent also publishes a DS record to link the chain of trust to the child.
Common DNS delegation issues
The parent lists NS records for servers that do not answer authoritatively for the child zone, often after a provider migration or a decommissioned server. Resolvers see SERVFAIL or timeouts on some queries, and failures look intermittent because they depend on which listed server is chosen.
The NS records in the parent differ from the NS records inside the child zone, usually because one side was updated and the other was not. Different resolvers cache different sets, so behavior varies and changes are slow to take effect.
A name server inside the delegated zone has no glue in the parent, or the glue holds an old IP address. Resolvers cannot reach the child servers, and the whole subdomain fails to resolve after a server renumbering.
The parent still holds a DS record for a key the child no longer uses, such as after a key rollover or a move to another provider. Validating resolvers return SERVFAIL for the subdomain while non-validating resolvers answer normally.