Subdomain NS Delegation Fails: Missing Glue Records

You delegated a subdomain to its own nameservers but resolution fails. The parent zone needs glue A/AAAA when NS targets live inside the subzone.

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

You want internal.yourdomain.com to be served from a private DNS infrastructure (BIND, NS1, 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’re delegating TO lives INSIDE the subzone you’re delegating, the parent must also publish A/AAAA records for those nameservers — otherwise resolvers face a chicken-and-egg problem (need to query ns1 to find ns1’s address, but can’t find ns1’s address without first querying ns1).

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. 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).

If you can avoid glue by using NS targets in a different zone (e.g. your DNS provider’s nameservers), 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

Most registrars call this “child nameservers”, “register host”, or “host registration”:

Namecheap: Domain → Advanced DNS → “Personal DNS Server” / register host.
GoDaddy: Domain settings → DNS → Host names.
Cloudflare Registrar: Account-level → Custom nameservers (limited).
Google Domains / Squarespace Domains: Domain → DNS → “Glue records”.

Add each NS hostname + its IP. The registrar pushes this to the TLD registry via EPP. Verify:

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

You should see ADDITIONAL section A/AAAA records for your NS hostnames.

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.

Verify

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).
Records resolve identically from at least three external networks (mobile data, public DNS server check tools, a different region’s VPS).
intodns.com or dnsviz.net for your subdomain show no missing-glue 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.

Q: Can I use just one nameserver?

Technically yes, practically no. Most TLDs require minimum 2 NS records for delegation. Two is the floor, four is robust.

Tags: #Troubleshooting #DNS #delegation #Debug