DNS NS records and delegation

What it means

An NS delegation tells a resolver which authoritative servers are responsible for a child DNS zone. The parent zone publishes the delegation NS RRset; the child zone normally publishes its own apex NS RRset. They may be related but changing only the child NS does not instantly rewrite the parent's referral. When the delegated nameserver is inside the child zone, the parent may need address glue so a cold resolver can contact it without a circular dependency.

Try it

Simulation — follow a resolver referral. Keep an in-domain ns1.example.com with matching address glue, then remove the glue. The model shows the missing address bootstrap instead of inventing an answer. Select an out-of-domain nameserver with a separately resolved address, or make the parent and child NS disagree. Step through referral, address discovery and optional child contact. Reset returns all choices and the trace.

How the mechanism works

A resolver looking for www.example.com can receive a referral from the parent zone containing NS names for example.com. If one such name is ns1.example.com, obtaining its address from example.com itself might require first contacting that same server. Glue consists of parent-supplied address records for that in-domain nameserver, breaking the dependency. The glue is not the website's www A or AAAA record and is not itself a new authoritative answer for the requested host. RFC 9471 clarifies handling of available glue in referral responses, including truncation when a response cannot fit.

For ns1.example.net, address discovery belongs to another DNS resolution path; lack of glue at the example.com parent does not establish failure. Parent referral and child apex NS are separately administered surfaces. A stale parent delegation can still send a cold resolver toward the former server after a child-zone NS edit. DNSSEC DS data at the parent adds a separate coordinated change risk.

Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.

In practice

For a planned delegation change, document the current registry/parent NS list, in-domain nameserver address dependencies, DS state and the destination authoritative zone. Prepare the replacement zone, including web and mail records, before requesting registrar-side changes. Read-only compare parent referral, nameserver addresses and child authoritative answers from an authorized environment. Stop if the new servers do not serve the expected zone or DS coordination is uncertain. Retain the previous delegation values and recovery authority; rollback means restoring the reviewed parent settings and allowing caches to expire, not toggling random records.

Limits and common mistakes

This is a deterministic two-zone cold-resolution fixture, not a resolver, DNS trace or availability test. Actual resolvers may have cached addresses, multiple NS targets, fallback transports and additional DNSSEC conditions. Missing bootstrap evidence in this toy case is not a universal outage diagnosis.

Key takeaways

The parent delegation determines the initial referral; changing child apex NS alone cannot redirect it. In-domain glue supplies address bootstrap for the delegated nameserver, while an external nameserver has a different resolution path. Inspect delegation and address evidence together before planning DNS changes.