Here’s a puzzle that sounds like a trick question but isn’t. Your domain is example.com. Its nameservers are ns1.example.com and ns2.example.com. A resolver wants the IP address for your website, so it needs to ask your nameserver. To ask your nameserver, it needs the address of ns1.example.com. And to get that, it has to ask… the nameserver for example.com. Which is ns1.example.com. Which it can’t reach, because it doesn’t have the address yet.

That’s not a contrived edge case. It’s the default. The most common way to name your nameservers puts them inside the very zone they’re responsible for, and doing that creates a circular dependency that DNS, as described in 1987, cannot resolve on its own. The whole system would deadlock on the first lookup of every such domain.

It doesn’t deadlock, obviously — the internet works. The thing that saves it is a small, slightly awkward piece of data called a glue record, and it lives in a place most people never look until the day their domain goes dark for no reason they can find.

Delegation, and where it breaks

DNS is a tree, resolved right to left. To find www.example.com, a resolver starts at the root, which tells it who runs com. It asks the com servers, which tell it who runs example.com. It asks those, and finally gets the answer. Each step down is a delegation: the parent zone doesn’t hold your records, it just points at the servers that do.

The pointing is done with NS records. The com zone contains, for your domain, something like:

example.com.   NS   ns1.example.com.
example.com.   NS   ns2.example.com.

Read that carefully and the trap is right there in plain text. The com zone is telling a resolver, “to learn about example.com, go ask ns1.example.com.” But ns1.example.com is a name under example.com — the exact zone the resolver is trying to reach and can’t yet. The NS record answers the question with a name that can only be resolved by first answering the question. The delegation eats its own tail.

This only happens because the nameserver’s name is inside the domain it serves. If your nameservers were ns1.somedns.net and ns2.somedns.net, there’d be no paradox: somedns.net is a different zone with its own delegation, and the resolver can go look it up independently. But naming your nameservers after your own domain is the norm — registrars nudge you toward it, big providers do it, it looks tidy — and the tidy choice is the one that would break DNS if nobody had planned for it.

The fix is in the parent’s hands

Somebody did plan for it. The answer is to make the parent zone hand over the address, not just the name.

When the com servers return that delegation, they don’t stop at the NS records. They also include the A (and AAAA) address records for the nameservers, riding along in a part of the response called the additional section:

;; AUTHORITY SECTION:
example.com.        NS    ns1.example.com.
example.com.        NS    ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    A     203.0.113.10
ns2.example.com.    A     203.0.113.11

Those two address records in the additional section are the glue. The com registry is holding a copy of your nameservers’ IP addresses and handing them out with every referral, so the resolver never has to resolve ns1.example.com the normal way. It gets the name and the address in the same breath. The circular dependency is broken because the parent supplies the one fact the child couldn’t supply about itself.

The name is exactly right. Glue is the substance that holds two zones together across the delegation seam — a little bit of the child’s data, stored in the parent, precisely because the child can’t be reached to provide it.

When you need glue, and when you don’t

Glue is only necessary when the nameserver’s name is inside the zone being delegated. RFC 9471 — the 2023 standard that finally nailed this down, and which we’ll get to — calls these in-domain name servers; older writing calls them in-bailiwick. ns1.example.com serving example.com is in-domain. It needs glue, full stop, or the domain is unresolvable.

If your nameservers live in a different zone entirely — ns1.cloudflare.com serving example.com — you need no glue at all. The resolver just resolves cloudflare.com through its own delegation, gets the address, and moves on. No paradox, no glue, nothing for the parent to store. This is quietly one of the reasons big managed-DNS providers use their own domain for nameservers: it sidesteps glue entirely, and glue is a thing that can go wrong.

There’s a middle case, too — a nameserver named in a sibling domain you also control — where glue may or may not be present: the rules say a server should include it if it fits, but don’t require it. But the sharp line is the one worth remembering: name your nameservers inside your domain and you are now depending on glue. Most people are, and most people have no idea.

The security twist: glue you should not believe

Here’s where it gets interesting, because the additional section is also a gift to attackers, and defending against that shaped how resolvers treat glue.

Records in the additional section are, by definition, unsolicited. You asked for example.com, and the response also contains addresses you didn’t ask about. What stops a malicious or compromised nameserver from stuffing the additional section with a record like www.yourbank.com. A 6.6.6.6 and poisoning your resolver’s cache with it?

The answer is bailiwick checking. A resolver will only accept glue that is within the bailiwick of the server that sent it — roughly, data the sending zone has authority to speak about. When the com servers hand you an address for ns1.example.com, that’s in bailiwick: it’s part of a delegation com is responsible for making. But if those same servers tried to slip you an address for www.yourbank.com, a sane resolver throws it away, because com’s referral has no business asserting addresses for an unrelated name.

This wasn’t always taken seriously. Resolvers in the 1990s cached out-of-bailiwick additional records more or less on sight, and early cache poisoning attacks did exactly the trick above; bailiwick checking was the fix. It wasn’t the end of the story. The Kaminsky attack of 2008 showed that even glue that passes the bailiwick check can be weaponized: race the real server with forged referrals for random names under the target domain, each carrying in-bailiwick glue that points at the attacker, and sooner or later one forgery wins and the resolver caches it. That’s why resolvers also randomize source ports and why they’re picky about which glue they’ll believe. Glue is necessary, but glue is also untrusted input arriving in a part of the packet nobody asked about, and treating it as gospel is how you get owned.

The footgun: glue goes stale

Now the operational failure, the one that generates confused support tickets.

Your glue lives in two places. There’s the A record for ns1.example.com inside your own zone, which you edit in your DNS provider’s control panel like any other record. And there’s the glue copy sitting up in the parent registry, which you set through your registrar — usually under a menu called “register a nameserver,” “host records,” “child hosts,” or, if you’re lucky, literally “glue records.” That registrar setting is pushed to the registry over EPP, and it is a completely separate act from editing your zone.

So picture this. You move your nameserver to a new IP address. You update the A record in your zone. Everything looks correct in your control panel. And your domain starts failing intermittently for reasons that make no sense, because the glue at the registry still points at the old, dead IP. Resolvers that reach for the parent’s glue get the stale address; resolvers that happen to already know your real address work fine. It’s inconsistent, it’s maddening, and the record you’d naturally check — the one in your own zone — is perfectly correct. The wrong copy is the one you forgot existed.

Diagnosing it means asking the parent what it’s handing out, not asking your own nameserver. Query the TLD servers for your delegation and look at the addresses in the additional section; if they disagree with your zone’s own A record for the same nameserver, you’ve found stale glue, and the fix is at the registrar, not in your DNS.

Glue is not optional (officially, since 2023)

For most of DNS’s life, the exact rules for glue in referrals were underspecified, and implementations disagreed in a way that occasionally bit hard. In particular: what should a server do when all the required glue doesn’t fit in the response? Some servers just dropped the glue that didn’t fit and sent an incomplete referral — leaving the resolver with names it couldn’t resolve and no hint that anything was missing. The domain would fail, silently, on nothing but a large delegation.

RFC 9471, published in September 2023 with the wonderfully blunt draft name “glue-is-not-optional,” updates the original 1987 spec to close that gap. It requires an authoritative server to return all the glue for in-domain nameservers in a referral. And if that glue won’t fit within the message size, the server must not quietly truncate the list — it must set the TC (truncated) bit, which tells the resolver “this answer is incomplete, ask again over TCP.” Better to force a slightly slower retry that gets complete glue than to hand back a fast answer that’s missing the one thing the resolver needs.

That a thirty-six-year-old protocol needed a 2023 RFC to say “yes, you really do have to send the glue, all of it” tells you how quietly load-bearing this little hack is. Nobody thinks about glue. It sits in the additional section, invisible, doing the one job that keeps self-referential delegations from deadlocking — until an IP changes, or a registry setting drifts, or a referral gets too big, and suddenly the most basic lookup in the world can’t complete.

The lesson glue teaches is the one DNS keeps teaching in different costumes: the internet is held together by small conventions agreed on decades ago, most of them invisible when they work, and the failures are never where you’re looking. You check your zone. The problem is in the parent. You check the nameserver. The problem is a record you didn’t know the registry was keeping. Glue is a good name for it in more ways than one — it’s what holds the thing together, and you only notice it when it lets go.