Subdomain NS Delegation Fails: Missing Glue Records

Delegated a subdomain to nameservers inside itself and resolution fails? The parent zone needs glue A/AAAA. Here is the dig diagnosis and the exact registrar fix.

Published: May 24, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

Fastest fix: if your NS record points at a hostname inside the zone you are delegating (for example internal.yourdomain.com. NS ns1.internal.yourdomain.com.), the parent must also publish A/AAAA “glue” records for those nameserver hostnames. Add them in the parent zone (for subdomain delegation) or via your registrar’s host-registration panel (for apex/domain delegation), then confirm with dig +trace internal.yourdomain.com that the ADDITIONAL section carries an address at the .com step. Per RFC 9471 (Sept 2023), a server answering a referral MUST return glue for in-domain nameservers, so when it is missing, resolution stalls.

You want internal.yourdomain.com to be served from a private DNS infrastructure (BIND, an internal Route 53 hosted zone, a Kubernetes ExternalDNS setup). You add an NS record at the parent: internal.yourdomain.com. NS ns1.internal.yourdomain.com.. Looks reasonable. Then nothing resolves. Or, worse, it resolves from inside your network but not from outside. The cause is missing glue records: when the nameserver you are delegating TO lives INSIDE the subzone you are delegating, the parent must also publish A/AAAA records for those nameservers. Otherwise resolvers face a chicken-and-egg problem (they need to query ns1 to find ns1’s address, but cannot find ns1’s address without first querying ns1).

The DNS term for this is an in-domain (in-bailiwick) nameserver: the NS hostname is itself a name under the delegated zone. Glue is the only thing that breaks the loop, and as of June 2026 the spec (RFC 9471) makes returning it mandatory for the parent.

Which bucket are you in?

One quick check tells you whether glue is even your problem. Run this from an outside network:

dig +trace internal.yourdomain.com

What `dig +trace` shows	Most likely cause	Jump to
Stalls at the `.com` step, NS listed but no address in ADDITIONAL	Glue never registered at the parent/registry	Cause 1, Cause 3
Reaches your NS but the address is an old/dead IP, then times out	Stale glue after an IP move	Cause 4
Works on IPv4, fails only from some networks/carriers	Missing AAAA glue	Cause 6
`dig @your-ns ...` answers but `dig @8.8.8.8 ...` does not	Records live only in the subzone, not the parent	Cause 2
Two registrars/providers return different NS IPs	Split config drift	Cause 5

Common causes

Ordered from most-common-by-far down to edge cases.

1. NS target lives inside the delegated zone but no glue at the parent

You set internal.yourdomain.com. NS ns1.internal.yourdomain.com. but did not add an A record for ns1.internal.yourdomain.com. at the parent. The parent zone has the NS pointer but no way to tell the resolver where ns1 actually is.

How to spot it: dig +trace internal.yourdomain.com stops at the NS step with “no answer” or hangs trying to resolve the nameserver address.

2. Glue records exist in subzone but not in parent

You added A records for ns1 inside the subzone (internal.yourdomain.com zone file has ns1 A 10.0.0.1). But the parent zone (yourdomain.com) does not have that same A record. Internal resolvers that already cached the subzone may work; external resolvers doing fresh lookups fail.

How to spot it: dig @8.8.8.8 internal.yourdomain.com fails. dig @ns1.internal.yourdomain.com internal.yourdomain.com succeeds. The data exists; the parent never told outsiders where to find it.

3. Registrar UI for glue records is non-obvious

For TLD-level glue (delegating an entire domain to nameservers within itself, e.g. yourdomain.com. NS ns1.yourdomain.com.), the glue must be registered at the TLD registry through the registrar — most registrars have a hidden “register host” or “child nameservers” panel separate from the DNS records UI.

How to spot it: You added the A records in the DNS panel but dig @a.gtld-servers.net yourdomain.com NS +additional from the TLD shows no additional A records — they aren’t visible at the registry.

4. Stale glue points to a decommissioned IP

You moved nameservers to new IPs. The subzone’s internal NS records got updated. The parent’s glue still points at the old IPs. Resolvers reach for the old addresses and time out.

How to spot it: dig +trace shows the resolver getting an additional A from the parent but timing out connecting to it.

5. Different glue at registrar vs DNS provider (split config)

Many setups have NS records in the DNS provider’s UI AND parent glue at the registrar. The two diverge. Some resolvers honor one, some the other.

How to spot it: dig yourdomain.com NS @registrar-side returns different IPs than dig yourdomain.com NS @dns-provider-side.

6. IPv6 glue missing while IPv4 glue exists

You set ns1 A 192.0.2.1 glue at the parent but no ns1 AAAA 2001:db8::1. IPv6-only resolvers cannot reach the nameserver.

How to spot it: Resolution works on v4 paths, intermittent failures from v6-first resolvers. Some mobile carriers see issues.

Before you start

Identify the parent zone, the delegated subzone, and which nameservers own each.
Know which registrar holds the parent domain and whether it manages DNS or just registration.
Have the IP addresses (v4 and v6 if applicable) of each delegated nameserver.
Save the current state of the parent NS records and the parent glue (or registrar host record list).

Information to collect

Output of dig +trace internal.yourdomain.com from an external network.
Output of dig @8.8.8.8 NS internal.yourdomain.com +additional.
Output of dig @a.gtld-servers.net yourdomain.com NS +additional (TLD’s view of your zone).
Registrar’s “host registration” or “child nameservers” page screenshot.
DNS provider’s NS record list for both parent and subzone.

Step-by-step fix

Choose path A (NS targets outside subzone) or path B (NS targets inside subzone — needs glue).

Step 1: Determine if you actually need glue

Glue is required only when the NS target’s name is INSIDE the zone being delegated (an in-domain nameserver). Examples:

Glue required: internal.yourdomain.com NS ns1.internal.yourdomain.com. (ns1 lives inside internal.yourdomain.com).
Glue NOT required: internal.yourdomain.com NS ns1.dnshost.com. (ns1 lives in dnshost.com, a separate zone, so the resolver looks it up independently).

RFC 9471 §3 draws the line precisely: a referral MUST carry glue for in-domain nameservers (or set TC=1 and force a retry over TCP if the UDP packet runs out of room), and SHOULD carry glue for sibling-domain nameservers. So if your NS target is in-domain, a parent that omits glue is non-conformant and resolution breaks. If it is a sibling or fully external name, glue is not your issue and you should look elsewhere (lame delegation, firewall, wrong NS IP).

If you can avoid glue by using NS targets in a different zone (for example your DNS provider’s nameservers, ns1.dnshost.com), do it. That eliminates this entire problem class.

Step 2: If glue is required, add A and AAAA records at the parent

In the parent zone (yourdomain.com):

ns1.internal.yourdomain.com.  3600  IN  A     192.0.2.1
ns1.internal.yourdomain.com.  3600  IN  AAAA  2001:db8::1
ns2.internal.yourdomain.com.  3600  IN  A     192.0.2.2
ns2.internal.yourdomain.com.  3600  IN  AAAA  2001:db8::2

Note these are records in the PARENT zone for names that LOOK like they belong in the subzone. That is what glue is — out-of-bailiwick lookups short-circuited by the parent.

Step 3: For apex-level delegation (yourdomain.com NS ns1.yourdomain.com), register glue at the TLD via registrar

When the in-domain nameserver lives at the apex (you are delegating the whole registered domain to a name inside itself), you cannot fix this from the DNS records UI alone. The registry stores apex glue as a host object, and only the registrar can create it over EPP. Menu labels differ by registrar; verified paths as of June 2026:

Namecheap: Domain List → Manage → Advanced DNS tab → “Personal DNS Server” section → Add Nameserver (hostname + IP).
GoDaddy: Domain Portfolio → select the domain → DNS → Hostnames → Add Hostname (Host prefix + IPv4/IPv6). GoDaddy processes the change within a few minutes, but allow up to a day for it to propagate to the registry and resolvers everywhere.
Squarespace Domains (this is where former Google Domains registrations now live; Google Domains shut down in 2024): domains dashboard → select the domain → DNS → Nameserver Registration → Add Host Record. Re-auth with your password or 2FA is required.
Cloudflare Registrar: there is no self-serve glue UI. Account custom nameservers require a Business or Enterprise plan, and to publish glue you must open a ticket with Cloudflare Support to add the hostnames and IPs to the registry. Note that glue host objects do not always carry over during a transfer into Cloudflare Registrar, so re-register them after any inbound transfer.

Add each NS hostname plus its IP. The registrar pushes this to the TLD registry via EPP. Verify it landed at the registry:

dig @a.gtld-servers.net yourdomain.com NS +additional

You should see ADDITIONAL section A/AAAA records for your NS hostnames. If the NS records appear but ADDITIONAL is empty, the host object was never created at the registry — the most common apex-delegation failure.

Step 4: Make the subzone authoritative for the glue addresses too

For consistency, the subzone (internal.yourdomain.com) should ALSO contain the same A records:

$ORIGIN internal.yourdomain.com.
@      IN  NS    ns1
@      IN  NS    ns2
ns1    IN  A     192.0.2.1
ns1    IN  AAAA  2001:db8::1
ns2    IN  A     192.0.2.2
ns2    IN  AAAA  2001:db8::2

When a resolver eventually queries the subzone directly, it gets the same answer. Glue is the bootstrap; in-bailiwick records are the canonical source.

Step 5: Verify end-to-end resolution from outside

dig +trace internal.yourdomain.com

You want to see:

Root nameservers → .com TLD.
.com TLD → your authoritative nameservers WITH addresses in ADDITIONAL.
Your nameservers → final answer.

Each hop has a clear A record. No hangs, no timeouts.

Also check from a different network (mobile data, a VPS in another region) — local DNS caching can mask the issue.

Step 6: Lower TTL during the change, raise after stability

Set TTL = 300 on the NS records and glue while you’re verifying. Once 24 hours pass clean:

ns1.internal.yourdomain.com.  86400  IN  A  192.0.2.1

Raise to 86400 (1 day) for stability. Long TTLs reduce query load on your nameservers and improve resolver cache hit rates.

How to confirm it’s fixed

Run all five; do not declare victory on dig +trace alone, since a warm cache can hide a still-broken registry record.

dig +trace internal.yourdomain.com completes cleanly with addresses in ADDITIONAL at every step.
dig @8.8.8.8 NS internal.yourdomain.com returns the NS records.
dig @8.8.8.8 ns1.internal.yourdomain.com returns the A record (resolved via parent glue).
For apex glue, dig @a.gtld-servers.net yourdomain.com NS +additional shows your hostnames with addresses — confirming the registry, not just your zone, has the data.
Records resolve identically from at least three external networks (mobile data, a different region’s VPS, a public DNS check tool). Run a full zone audit at DNSViz or intoDNS and confirm no missing-glue or lame-delegation warnings.

Long-term prevention

Prefer NS targets in a DIFFERENT zone than the one being delegated whenever possible. Eliminates glue entirely.
Document glue records as a checklist item in any zone-delegation runbook — they are often forgotten.
Use DNS-as-code (Terraform dns_* resources, OctoDNS) so glue is version-controlled alongside the delegation.
After every nameserver IP change, immediately update parent glue AND verify with dig +trace from outside.
Add intodns.com or dnsviz.net checks to a weekly cron — they surface glue issues before users do.

Common pitfalls

Adding A records in the SUBZONE for the nameservers and assuming that is enough. The PARENT needs glue too.
Updating nameserver IP at the subzone but forgetting the parent glue at the registrar.
Glue records added in the DNS provider’s UI but not pushed to the TLD registry (some registrars require a separate “child nameserver” registration).
Using lame delegation — listing nameservers as NS that don’t actually answer for the zone (e.g. left over from an old provider).
Confusing “vanity nameservers” (cosmetic, e.g. ns1.yourbrand.com aliased to provider) with real delegation needing glue.

FAQ

Q: Why does it work from inside my network but not outside?

Internal resolvers may have cached the subzone’s records directly, or have a stub zone configured. External resolvers do the full delegation chain and fail at the missing glue. Internal-only success is a strong signal of a glue problem.

Q: My registrar doesn’t have a glue / child nameserver page. What do I do?

Either your registrar doesn’t support glue (rare on real TLDs) or it’s hidden. Contact support and ask about “EPP host registration” or “child nameserver” — every TLD-accredited registrar must support this. If they refuse, transfer to a registrar that does.

Q: How long do TLD registries cache glue records?

The TTL on the additional records returned by the TLD nameservers — typically 1-2 days at .com/.net. Changes propagate within that window from the moment the registrar pushes the update via EPP. Squarespace and most registrars quote 24-48 hours for glue changes to be visible everywhere.

Q: dig +trace returns SERVFAIL or just hangs at the .com line. What does that mean?

The TLD handed back a referral with no usable address for your nameserver. That is the textbook missing-glue symptom: the .com servers know the NS name but were never given its IP, so the resolver has nowhere to go. Confirm with dig @a.gtld-servers.net yourdomain.com NS +additional — an empty ADDITIONAL section means the host object is not registered.

Q: I added the A records inside my own zone. Why is glue still “missing”?

Records inside the delegated zone are authoritative but unreachable until something tells the resolver where that zone’s nameservers are. That bootstrap copy lives in the parent, not the child. For apex delegation the parent is the TLD registry, which is why this often requires a registrar host object rather than a zone-file edit.

Q: Can I use just one nameserver?

Technically yes, practically no. Most TLDs require a minimum of 2 NS records for delegation. Two is the floor, four is robust. If both share a single network or provider, you have a redundancy gap regardless of the count.

Tags: #Troubleshooting #DNS #delegation #Debug