Glue Records and DNS Delegation: Why Changing Nameservers Can Silently Break a Domain

A nameserver hosted on the same domain it serves creates a circular dependency — and "glue records" are the special DNS mechanism that breaks the circle

When a domain's nameservers are hosted within that same domain (e.g., example.com uses nameservers ns1.example.com and ns2.example.com), a fundamental chicken-and-egg problem arises: to find ns1.example.com's IP address, you'd normally query example.com's nameservers — but ns1.example.com is one of example.com's nameservers. Glue records are the DNS mechanism that resolves this circularity, and understanding them explains a specific category of "my nameserver change broke everything" problems.

The delegation chain and where glue fits

When a resolver looks up www.example.com, it follows a chain of delegations:

1. Query the root nameservers → referred to the .com TLD nameservers
2. Query the .com TLD nameservers for example.com → referred to example.com's nameservers (e.g., ns1.example.com, ns2.example.com)
3. Query ns1.example.com for www.example.com → get the answer

Step 2 is where the circularity problem lives: the .com TLD nameservers need to tell the resolver "go ask ns1.example.com" — but to query ns1.example.com, the resolver needs ns1.example.com's IP address, which would normally require... querying example.com's nameservers, which is the very thing being delegated.

Glue records solve this: the .com TLD zone stores not just "the nameservers for example.com are ns1.example.com and ns2.example.com" but also the IP addresses of those nameservers, directly within the .com zone — as "glue." The resolver receives both the nameserver names and their IP addresses in the same referral response from the TLD, without needing a separate lookup that would create the circular dependency.

When glue records are required vs not needed

Glue is required when a nameserver's hostname is "in-bailiwick" — i.e., within the domain being delegated, or within a domain that itself depends on this delegation. ns1.example.com for the domain example.com is the clearest case — the nameserver's own name is a subdomain of the domain it serves.

Glue is not needed when nameservers are "out-of-bailiwick" — hosted on a completely different domain that doesn't depend on this delegation. If example.com uses ns1.dnsprovider.com and ns2.dnsprovider.com (a third-party DNS provider's nameservers, on their own domain), there's no circularity — looking up ns1.dnsprovider.com's IP address involves following dnsprovider.com's delegation chain, which is entirely independent of example.com's delegation. No glue is required in this case.

This is one reason many domains use third-party DNS providers' nameservers (e.g., ns1.cloudflare.com-style names) rather than self-hosted in-domain nameservers — it avoids the glue record requirement entirely, simplifying the delegation chain.

How glue records are managed (and why this trips people up)

Glue records aren't configured in your domain's own DNS zone — they're configured at your domain registrar, as part of the delegation information for nameservers that are in-bailiwick.

The practical workflow problem this creates: if you're migrating example.com from one DNS provider to another, and your old setup used in-bailiwick nameservers (e.g., ns1.example.com pointing at your old provider's IP), and your new setup will also use in-bailiwick-style names (e.g., a new ns1.example.com pointing at a different IP for the new provider) — the glue records at the registrar need to be updated to point to the new IP addresses. If you only update the DNS records within example.com's zone (at the new provider) but don't update the glue records at the registrar, resolvers following the delegation chain will receive the old glue (old IP addresses) from the TLD, and will attempt to query nameservers at IPs that are no longer serving example.com's zone — resulting in resolution failures that can be very confusing to diagnose, because the new DNS provider's records might be perfectly correct; the problem is entirely in stale glue at a layer (the registrar/TLD) that's easy to overlook.

Debugging glue-related issues

Symptom pattern: a domain's DNS appears correctly configured when checked directly against the new nameservers (querying ns1.newprovider.com or even ns1.example.com at its new IP directly gives correct answers) — but resolution fails or gives stale results when queried normally (via the standard delegation chain, starting from root/TLD).

Diagnostic approach: querying the TLD nameservers directly for the delegation information (what nameservers and glue do they have on file for this domain) reveals whether the glue matches the intended new configuration or still reflects old IP addresses — a mismatch here, despite the new provider's zone itself being correctly configured, points specifically to a registrar-level glue record update that hasn't been completed.

The fix: glue record updates are made through the domain registrar's interface (sometimes under terminology like "nameserver IP addresses" or "host records" associated with the domain, distinct from the DNS zone records themselves, which are managed wherever the domain's DNS is hosted).

IPv6 glue: AAAA glue records

Just as A records provide IPv4 glue, AAAA records can provide IPv6 glue for in-bailiwick nameservers that have IPv6 addresses. As IPv6 adoption has increased, ensuring both A (IPv4) and AAAA (IPv6) glue records are correctly configured for in-bailiwick nameservers — where the registrar interface supports specifying both — has become relevant for ensuring resolution works correctly for resolvers that may prefer or require IPv6 connectivity to reach nameservers.

Lame delegation: a related but distinct problem

"Lame delegation" refers to a situation where a domain's delegation (the NS records at the parent zone, i.e., what the TLD says are this domain's nameservers) lists nameservers that aren't actually configured to serve the zone — e.g., the TLD says example.com's nameservers include ns3.example.com, but ns3.example.com either doesn't respond, or responds but doesn't have the example.com zone configured (perhaps it was decommissioned, or was never properly set up).

This is different from a glue record problem (where the IP address associated with a correctly-listed nameserver is wrong) — lame delegation is when the nameserver itself (regardless of whether its IP is correctly glued) isn't actually serving the expected zone. Both can produce similar symptoms (resolution failures or inconsistent results depending on which nameserver a resolver happens to query), but the fixes differ: a glue record problem is fixed at the registrar (correcting IP addresses); a lame delegation problem requires either properly configuring the lame nameserver to serve the zone, or removing it from the NS record set (at whichever location is authoritative for that NS record set — which, confusingly, can itself be a point of distinction between the NS records within the zone vs the NS records at the parent/delegation level, which should match but don't always).

How to use the NS Lookup tool on sadiqbd.com

1. Check the nameservers currently delegated for a domain — as seen from the parent zone's perspective (the delegation)
2. Compare against the nameservers a domain's own zone claims for itself — the NS records within the zone should match the delegation, but discrepancies can occur and are worth identifying
3. For in-bailiwick nameservers, check glue is correct — if a domain uses nameservers within its own namespace, verify the IP addresses associated with those nameservers (via glue at the registrar level) match where the zone is actually hosted
4. Use during nameserver migrations — checking both the new provider's direct responses and the delegation/glue as seen from the TLD helps distinguish "new zone is correctly configured" from "delegation/glue still needs updating"

Frequently Asked Questions

Why do some domains use nameservers like ns1.example.com instead of just using their DNS provider's nameservers directly? This is sometimes done for branding/consistency reasons (having nameservers that appear to be part of your own domain), or in situations where an organisation runs its own DNS infrastructure rather than using a third-party provider. The trade-off is the glue record management overhead described above — third-party provider nameservers (out-of-bailiwick) avoid this complexity, which is part of why they're commonly used, particularly for domains that don't have a specific reason to self-host DNS.

If I change my DNS provider but keep using ns1.example.com-style nameserver names, do I need to update anything besides my DNS zone? Yes — if ns1.example.com and similar names are in-bailiwick (within example.com itself), and the new provider's nameservers are at different IP addresses than the old provider's, the glue records at your registrar need to be updated to the new IP addresses, separately from configuring your DNS zone at the new provider. This is the step that's easy to overlook, as described above.

Is the NS Lookup tool free? Yes — completely free, no sign-up required.

Try the NS Lookup tool free at sadiqbd.com — check any domain's authoritative nameservers and delegation configuration instantly.