Missing glue
When the delegation needs an address the parent didn't include
A glue record is one of the less-celebrated DNS primitives, and when it is absent the failure looks exactly like a timeout — no error, no NXDOMAIN, just silence. Understanding why requires tracing the exact moment the resolver runs out of information to proceed.
The standard delegation works cleanly: the parent zone carries NS records pointing at nameservers, and those nameservers live outside the delegated zone, so their addresses can be resolved independently. When you delegate example.com to ns1.otherdomain.net, a resolver that already knows how to find .net can chase that address without touching example.com at all. No glue needed.
The moment the nameserver hostname falls inside the zone it serves, that independence is gone. If example.com is served by ns1.example.com, a resolver asking the .com zone for the delegation receives NS records pointing at ns1.example.com — and then immediately needs to resolve ns1.example.com to find where to send the query. That resolution requires asking example.com, which requires asking ns1.example.com, which requires resolving ns1.example.com. The chain cannot start. This is the classic in-bailiwick nameserver problem, and glue is the only exit: the parent zone carries an A or AAAA record for ns1.example.com as additional data in the delegation response, outside the normal authority of example.com, simply to break the cycle.
RFC 1034 ↗ defines the requirement, and the resolver's behaviour in its absence is specified clearly enough: if the additional section carries the address, proceed; if not, a conforming resolver may attempt a separate lookup for the nameserver's address, but that separate lookup leads straight back into the same dependency. Authoritative servers for the parent are required to provide glue when the nameserver is in-bailiwick. Registries and registrars surface this as the glue record entry at delegation time.
What actually breaks
Missing glue produces a circular dependency that resolvers time out of rather than report distinctly. The zone goes dark. The failure is total — every record type, every subdomain — because the resolver cannot reach the authoritative server for any query. It does not fail partially.
The scenario turns up in two patterns. The first is an operator who registers nameservers with in-bailiwick names and then either omits the glue at the registrar or changes the server's IP without updating it. The parent zone still points at the old address (or none), so the new server is unreachable from outside. The second is a zone transfer or migration where the NS records are updated before the glue is — a sequencing failure that leaves a brief but complete outage window.
Registrars vary in how well they enforce glue. Some validate at submission and refuse to publish a delegation without accompanying address records for in-bailiwick hosts. Others accept the NS records and wait for the operator to notice. ICANN ↗'s registry agreement obligations include data accuracy provisions, but operational enforcement of glue completeness at the registrar layer is inconsistent in practice.
The fix is unambiguous: supply the IPv4 and IPv6 addresses of every in-bailiwick nameserver to the registrar, keep them current whenever an address changes, and update glue before or simultaneously with any server migration — never after. If the new address is not in the parent zone before the server moves, the zone is unreachable the moment the old address stops responding.
Choosing out-of-bailiwick nameserver names removes the dependency entirely and is often the cleaner architectural choice for operators who want fewer moving parts in a delegation. When in-bailiwick names are the operational preference — for uniformity, for branding, or simply because the nameserver genuinely lives in the served domain — glue is mandatory, and its accuracy is a parent-zone responsibility that cannot be delegated downward to the zone itself.
The pointer and the address have to travel together. When they do not, the resolution chain stops at the delegation, and everything below it is unreachable for as long as the parent carries incomplete information.
Choosing out-of-bailiwick nameserver names removes the dependency entirely and is often the cleaner architectural choice for operators who want fewer moving parts in a delegation.
When they do not, the resolution chain stops at the delegation, and everything below it is unreachable for as long as the parent carries incomplete information.