ClueDNSSearch

concept · intermediate

DNS zones, delegation, parent and child NS, and glue

Understand zone boundaries, referrals, parent and child nameserver data, and the address records that break nameserver lookup dependencies.

Published
Jul 28, 2026
Last verified
Review by
Risk
read-only
Provider
neutral

The DNS namespace is one hierarchy, but administrative responsibility is split into zones. Delegation creates a boundary where a parent directs resolvers to the authoritative servers for a child zone.

Namespace and zone are not synonyms

A domain is a node and the names below it in the namespace. A zone is the portion of that namespace served as one administrative unit, excluding separately delegated child zones.

For example, the example.com zone can contain:

example.com.
www.example.com.
mail.example.com.

If shop.example.com is delegated to another authoritative service, the example.com zone retains the delegation records, while the shop.example.com zone holds authoritative data below that new zone apex.

DNS terminology calls the boundary a zone cut [1].

What the parent publishes

At a delegation point, the parent zone publishes NS records that identify the child’s authoritative nameservers. A referral response uses those records to direct an iterative resolver toward the child.

For the reserved example example.com, a simplified parent-side delegation might be:

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

For a registered domain, the registrant usually submits this nameserver set through the registrar. The registry then places the delegation in the top-level-domain zone.

Changing NS records only inside the child zone generally does not change this parent-side delegation.

What the child publishes

The child zone normally publishes NS records at its own apex as authoritative data:

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

The parent NS RRset is delegation data. The child-apex NS RRset is authoritative data from the child zone. They are maintained through different control paths and can have different TTLs.

They should identify a coherent authoritative service. A mismatch can produce inconsistent behavior, extra queries, or operational confusion even when some lookups still succeed.

Glue breaks an address dependency

An NS record contains a nameserver name, not its address. A resolver may need an A or AAAA record for that nameserver before it can follow the referral.

If a delegated zone uses an in-domain nameserver such as ns1.shop.example.com for shop.example.com, resolving the nameserver address would otherwise require first reaching the very child service whose address is unknown. The parent supplies address records as glue to break that dependency.

RFC 9471 clarifies that referral responses must include all available glue for in-domain nameservers, or signal truncation when message size prevents that [3].

Glue is not ordinary parent authority

Glue appears in the parent context to make the delegation reachable. The child zone remains authoritative for the nameserver’s address when that name is inside the child.

That means:

  • glue can be necessary for reaching the child;
  • glue and the child’s authoritative address data can disagree;
  • a resolver may treat glue with special trust and caching rules; and
  • updating the child address record alone may not update registry-held glue.

When an in-domain nameserver address changes, coordinate both the authoritative address record and the registrar or registry path that maintains glue.

Out-of-domain nameservers

If example.com uses ns1.example.net, the resolver can resolve the nameserver’s address through the example.net delegation. Glue at the com parent may be unnecessary for that particular dependency.

Sibling and cyclic arrangements are more complicated. RFC 9471 distinguishes in-domain, sibling, and cyclic-sibling glue behavior. Prefer a nameserver design whose dependencies remain easy to resolve and operate.

Delegation and DNSSEC meet at the parent

For a signed child zone, the parent can also publish a DS record. The DS record links the parent side of the DNSSEC chain of trust to DNSKEY material in the child zone.

NS and DS serve different purposes:

  • NS tells a resolver where the child is served;
  • DS tells a validating resolver which child key material the parent authenticates.

Changing authoritative providers without coordinating DS state can make an otherwise reachable zone validate as bogus.

Inspect both sides safely

For a delegation problem, capture:

  1. parent-side NS and any glue;
  2. child-apex NS from each authoritative server;
  3. nameserver A and AAAA answers from their authoritative zones;
  4. DS at the parent and DNSKEY at the child when DNSSEC is enabled; and
  5. response codes, authoritative flags, TTLs, and observation times.

The DNS architecture defines referrals and zone boundaries [2]. Comparing both sides shows whether the fault belongs to registration/delegation, zone publication, nameserver addressing, or validation.

Next step

Place this delegation model in context by examining the DNS root system.