How DNS Delegation Works: NS, Glue & Subdomains

DNS is not one big database. It is a tree of zones, each run by whoever is responsible for that part of the namespace. Delegation is how one zone hands responsibility for a name to another set of servers. It is also where most "my domain stopped working" problems start.

The tree: root, TLD, your zone

Take www.example.com. Three zones are involved:

• The root zone knows which servers run each top-level domain, including com.
• The com zone, run by the registry, knows which servers run example.com.
• The example.com zone, hosted by your DNS provider, holds the actual records, such as the address for www.

Each step down the tree is a delegation: the parent zone publishes NS records that say "for this name, ask these servers".

What a resolver actually does

A recursive resolver with an empty cache finds www.example.com like this:

1. It asks a root server. The root replies with a referral: the NS records for com.
2. It asks a com server. That server is not authoritative for example.com, so it also replies with a referral: the NS records for example.com, often with their IP addresses.
3. It asks one of the example.com servers, which answers authoritatively with the A record.

You can watch the second step yourself by asking a .com server directly with recursion turned off:

dig @a.gtld-servers.net example.com NS +norecurse

The answer section will be empty, the aa (authoritative answer) flag will be absent, and the NS records will appear in the authority section. That is what a referral looks like.

Where your registrar fits in

When you set nameservers in your registrar's control panel, the registrar sends them to the registry, which publishes them as the NS records in the parent zone. Your registrar does not usually host your records—your DNS provider does, and the provider's zone also contains NS records of its own.

So every delegated domain has two lists of nameservers:

• the parent-side list, published by the registry and changed through your registrar;
• the child-side list, the NS records inside your own zone.

Resolvers use the parent list to find your zone, then often prefer the child list once they have it. When the two disagree, behaviour gets unpredictable.

What are glue records?

If your nameserver is named inside the zone it serves—say ns1.example.com for example.com—there is a chicken-and-egg problem: to find the address of ns1.example.com you would have to ask ns1.example.com. The parent solves this by publishing the nameserver's address alongside the referral. These addresses are called glue.

Glue is set at your registrar, often under "child nameservers", "host records" or "register nameserver". If the server's IP changes, the glue must be updated too, or resolvers will keep going to the old address.

Delegating a subdomain to another DNS provider

Delegation isn't only for whole domains. You can hand a subdomain such as app.example.com to a different provider—common when a platform or team manages its own records. Your registrar isn't involved: the delegation lives in your own zone, which is the parent of the subdomain.

1. Create the zone for app.example.com at the new provider, add its records, and note the nameservers it assigns.
2. In the example.com zone, add NS records for app pointing at those nameservers:

   app.example.com.  3600  IN  NS  ns-101.provider.net.
   app.example.com.  3600  IN  NS  ns-102.provider.net.

3. Remove any other records for app, and for names below it, from the parent zone. Once delegated, the parent's copies are ignored.
4. If example.com is signed with DNSSEC and the new provider signs the subdomain, add its DS record to the parent zone too. If the provider doesn't sign it, the NS records alone make it an unsigned delegation, which is valid.

Glue is needed only if the subdomain's nameservers are named inside the subdomain itself, such as ns1.app.example.com. Check the result with dig app.example.com NS +trace, which follows each referral down from the root.

What is a lame delegation?

A server listed in a delegation that does not actually serve the zone—it refuses queries, returns errors or answers without the authoritative flag—is called lame. It typically happens after moving to a new DNS provider while the old provider's nameservers stay listed, or when a zone is deleted at a provider before the delegation is changed.

Resolvers usually recover by trying another server, so a lame server often causes slowness and intermittent failures rather than a full outage. That makes it easy to miss.

When the parent has no delegation

If the parent zone answers NXDOMAIN for your domain, nothing below it can work. Public DNS can't tell you why, but the usual reasons are:

• the domain has expired or is in its redemption period;
• the registrar or registry has placed it on hold (clientHold or serverHold);
• it was registered without nameservers, or very recently;
• it was never registered.

The registry's RDAP service is the authoritative source for registration status. The nameserver check queries the parent servers directly, compares their answer with each of your nameservers, and looks up the registry status for you.