Glue records and lame delegation: how broken NS delegation breaks DNS

How delegation works, and where it gets circular

DNS resolves names by walking down a hierarchy: the root zone points a resolver to a TLD’s name servers, the TLD points it to a domain’s name servers, and the domain’s name servers answer for everything under it. RFC 1034 describes this delegation as a chain of NS records, each pointing to the name of a server responsible for the next zone down — not its IP address. That distinction is the whole problem glue records exist to solve.

If example.com delegates to a name server called ns1.example.com, a resolver needs that server’s IP address to query it — but ns1.example.com is itself a name inside the very zone the resolver hasn’t been able to reach yet. Asking “what’s the IP of ns1.example.com?” would normally mean asking example.com’s name servers, which is circular: you’d need to already be able to reach the server to find out how to reach it.

Glue records: breaking the circle

RFC 8499 defines glue records as the address records — A or AAAA — published at the parent zone (the .com zone, in this example) alongside the delegating NS records, giving a resolver the IP address of an in-domain name server directly, without needing to resolve it through the zone it’s delegated to. This is why registrars ask for “nameserver IP addresses” specifically when a domain’s own name servers live inside that same domain: that information becomes glue, stored at the parent, and without it the delegation would be unresolvable for any server whose name falls inside the zone being delegated. A name server hosted under a completely separate domain (a common setup with third-party DNS providers) has no such circular dependency and needs no glue at all.

Lame delegation: when the NS record points to a server that doesn’t answer

A separate, and more common, DNS delegation failure is a lame delegation — RFC 8499 defines it as a name server listed in a zone’s NS records that is not actually configured to serve that zone. This happens in ordinary, unglamorous ways: a name server gets decommissioned or repurposed but the NS record pointing to it is never removed; a domain migrates DNS providers and an old provider’s server is left in the NS set; or a secondary server was simply never set up to transfer and serve the zone it was listed for. Whatever the cause, a resolver that happens to query a lamely-delegated server gets a timeout, a refusal, or an answer for an entirely different zone — the delegation points somewhere that can’t actually help.

Why this matters even when most queries still work

Lame delegation rarely breaks a domain outright, because resolvers typically try multiple listed name servers and move on after one fails to answer — which is exactly why lame delegations often go unnoticed for a long time. The cost is intermittent: resolution becomes slower (extra round-trips to time out against the lame server before succeeding elsewhere) and less reliable, with the risk rising sharply if the working servers also have an outage, since a domain with lame delegations effectively has fewer functioning name servers than its NS record set implies.

How to check and fix it

Pull your domain’s current NS record set with AdminKit’s DNS lookup tool, then query each listed server directly for your zone and confirm it answers authoritatively — a server that times out, refuses, or answers for the wrong zone is lame. Whois/RDAP is a useful cross-check if the NS records themselves look unexpected, since it shows what your registrar has on file, which should match. The fix is simply removing or correcting the stale NS entry at your registrar or DNS provider so every listed server is one that’s actually configured and reachable for your zone.

Related checks

Delegation correctness and zone-transfer exposure are two distinct ways a domain’s DNS can be misconfigured without an obvious symptom day to day — see our guide on what is a DNS zone transfer (AXFR) for the transfer-exposure side, and DNS propagation and TTL explained for how caching behavior can make a delegation fix take time to be visible everywhere even after it’s corrected.