The delegation chain
DNS is a tree, and no single server knows all of it. Resolution works by asking a series of servers which server to ask next. A query for a name under a generic top-level domain begins at the root, which answers with the nameservers for that top-level domain; those answer with the nameservers for the domain; and those finally answer with the record you asked for. Each of those hand-offs is a delegation, and each is expressed as a set of NS records in the zone above.
The important property of this design is that authority is always granted from above. A zone cannot claim authority over itself in any way that a resolver will honour. Whatever a domain's own nameservers assert, the parent's delegation is what sends traffic to them in the first place, and if the parent points somewhere else then that is where everything goes.
Parent and child copies
Because NS records exist both in the parent zone and inside the delegated zone, there are always two copies, and they can disagree. The distinction is worth stating plainly:
Two copies, one authority
| Copy | Set by | Effect |
|---|---|---|
| Parent delegation | The registry, via the registrar | Decides which servers resolvers contact. This is the one that matters.Visible in the whois record and in an RDAP response as the nameserver list. |
| In-zone NS set | Whoever operates the zone | Informational. Should match the parent; when it does not, the parent wins and the mismatch is a latent fault.A stale in-zone set is a common leftover after a provider migration, and it can survive for years without visible symptoms. |
The practical rule is to read the delegation from the registry side. A registrar's control panel can show an intended configuration that was never published; a zone can advertise servers it no longer uses. The registry's answer is the only one that describes what is happening.
The undelegated state
Here is the state that causes the most expensive mistakes. A domain can be registered, fully paid, locked against transfer, and have no nameservers whatsoever. Nothing is wrong with the registration. There is simply nothing in the parent zone pointing anywhere, so a resolver asking about the name receives an authoritative answer that the name does not exist.
That answer is NXDOMAIN, and it is identical to the answer for a name nobody has ever registered. Every consequence follows from that identity. Availability checkers that work by resolution report the name as free. Certificate issuance fails, because the challenge cannot be served. Mail bounces permanently rather than deferring. Monitoring reports the host as down rather than misconfigured. And a domain in this state is invisible to anything that does not read the registry directly.
The check that settles it
Resolution answers a different question from registration, so ask both. A registry query, whois or RDAP, tells you whether the name is registered and to whom it is delegated. A DNS query tells you whether that delegation resolves. When the first says "registered, no nameservers" and the second says NXDOMAIN, nothing is broken and nothing is available.
Glue records and the circular problem
If the nameservers for example.com are themselves named
ns1.example.com and ns2.example.com, a resolver has a problem: to find
the servers it must resolve a name that only those servers can answer for. The parent zone breaks
the circle by publishing the servers' addresses alongside the delegation. Those additional address
records are glue.
Glue is only ever needed for in-domain nameservers, which is why it has largely disappeared from everyday practice: most domains now delegate to a third-party provider whose nameservers live under the provider's own domain and resolve independently. Where glue does exist it needs to be maintained: a nameserver that moves address and leaves stale glue behind produces intermittent, partially-cached failures that are very hard to diagnose from the outside.
What happens during a change
Changing delegation has two clocks running on it, and conflating them is why "DNS propagation" is usually described so vaguely. The registry clock is short: an update submitted through a registrar typically appears in the parent zone within minutes. The caching clock is long: resolvers that already hold the old delegation are entitled to keep using it until its TTL expires, and the TTL on a top-level domain's delegation is commonly measured in days rather than hours.
There is a second, subtler cache. If the name previously returned NXDOMAIN, that negative answer was also cached, for a period the previous SOA record specified. A newly delegated domain can therefore resolve for some users and not for others, for a while, with nothing at all wrong with the new configuration. Waiting is the fix, and lowering TTLs before a planned move is the way to shorten the wait next time.
Reading a delegation
Three questions, in order. Is the name registered: from the registry, not from resolution. What does the parent delegate it to: from the registry's nameserver list. Does that delegation answer, tested with a DNS query against those specific servers rather than a general lookup. If the first answer is yes and the second is empty, the third question does not apply and NXDOMAIN is the correct result rather than a fault.
For what happens to delegation when a registration lapses, and it is withdrawn well before the name is released, see the domain lifecycle. For the record types the delegation points at, see DNS record types.
