What Are DNS Glue Records and When Do You Need Them

What Is a Glue Record?

A glue record is the IP address of a nameserver, published not in your own zone but one level up — in the parent zone, at the registry, through your registrar. It exists to break a circular dependency.

Take example.com with nameservers ns1.example.com and ns2.example.com. A resolver that wants to look up www.example.com first asks the .com servers who is authoritative for example.com. The answer is "ns1.example.com and ns2.example.com". To ask those servers anything, the resolver needs their IP addresses — but the A records for ns1.example.com live inside example.com, on the very servers it is trying to find. Without help, the lookup can never start.

The glue record is that help: alongside the NS records, the .com servers hand out the IP addresses of ns1 and ns2 in the additional section of the response. The resolver uses them, reaches the nameservers, and the zone works.

You can see glue in a real delegation by asking a TLD server about your own domain (the real example.com is delegated to external nameservers, so it shows none):

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

The authority section lists the NS names; the additional section lists their glue addresses. If a nameserver name is inside the zone and nothing appears for it in the additional section, glue is missing.

When Glue Records Are Required

Glue is required exactly when a nameserver's hostname is inside the zone it serves — DNS people call this an in-bailiwick nameserver.

Required: example.com delegated to ns1.example.com and ns2.example.com. Both names are under example.com, so both need glue.

Not required: example.com delegated to ns1.hosting-provider.net and ns2.hosting-provider.net. A resolver finds those addresses through the .net delegation of hosting-provider.net; example.com's registrar has nothing to add. This is the everyday case when you use your DNS provider's default nameservers.

A mixed case: example.com delegated to ns1.example.com and ns3.seconddns.com — one in-bailiwick name that needs glue, one external name that does not. This is the typical shape when your own server is the primary and a hosted secondary answers under its own hostname.

The rule is per nameserver name, not per zone: check each NS record and ask whether that name lives inside the zone being delegated.

Where Glue Records Live

Glue is not a record you add to your own zone file. It belongs to the parent zone — the TLD registry — and the only way to put it there is through your registrar, because the registrar is who talks to the registry on your behalf.

Every registrar exposes this somewhere in the domain's settings, under names that vary a lot:

- "Register a nameserver" / "Register host" - "Child nameservers" / "Child hosts" - "Host records" / "Glue records" - "Private nameservers" / "Custom nameservers"

Whatever it is called, the form asks for two things: the nameserver hostname (ns1.example.com) and its IP address (IPv4, and IPv6 if you have it). Once submitted, the registry publishes the glue in the TLD zone; from then on, the .com servers answer with it.

Two consequences follow. The glue is a copy of your nameserver's address, maintained by hand at the registrar — if the server's IP changes, the glue does not change with it. And the record in your own zone (the A record for ns1.example.com) still has to exist and match: resolvers use the glue to get started, then trust what your zone says.

What Breaks Without Glue

Missing glue. The delegation points at ns1.example.com, but the registry has no address for it. Resolvers cannot reach the nameservers; the domain does not resolve at all. Some resolvers try harder than others, so the failure is often inconsistent — "works on my machine, not for customers" — which makes it hard to diagnose.

Stale glue. You moved the server, updated the A record in the zone, and forgot the registrar. The registry keeps handing out the old IP. Resolvers that follow the glue reach a dead address or, worse, whoever now owns that IP. Because most resolvers cache the working nameserver for a long time, this breakage can appear days after the migration.

Glue without a matching A record. The registry says ns1.example.com is 192.0.2.10, your zone says nothing or says something else. Glue is not authoritative: once a resolver learns the address from the zone itself, it uses that instead of the glue. So a wrong A record in the zone overrides correct glue, while a missing A record leaves the glue in effect. Keep both in step.

Lame delegation. The glue is correct, the address answers, but the server does not actually serve the zone — typical when a nameserver was decommissioned or a zone was never loaded on a secondary. Some ccTLD registries check for this when a delegation changes (gTLD registries do not), and monitoring tools flag it; resolvers treat the server as broken and fall back to the others, if there are any.

All four fail silently from the operator's side: nothing in your logs says "glue is wrong". The symptom is always downstream — intermittent resolution failures, slow lookups, mail delays — so it pays to check delegation explicitly.

Checking Delegation and Glue With dig

Trace the delegation from the root down to see exactly what each level hands out:

dig +trace www.example.com @1.1.1.1

The resolver is named explicitly because +trace asks it only for the root NS set and walks the delegation itself from there; any resolver that returns that set works.

In the output, find the step where the TLD servers answer for example.com: the NS records there are the delegation. Note that +trace prints only the delegation itself, not the additional section, so it does not show glue. To see the glue, pick any authoritative server of the TLD and ask it for the NS set directly:

dig NS example.com @a.gtld-servers.net +norecurse

The additional section shows glue as the parent sees it; an in-bailiwick nameserver with no entry there has no glue. Compare it with what your own zone says:

dig A ns1.example.com @ns1.example.com +short

The two addresses must match. Finally, confirm every listed nameserver actually serves the zone and agrees on the version:

dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +short

Both should answer authoritatively with the same serial. A REFUSED or SERVFAIL here is a lame delegation; a serial that lags on one server means zone transfers are not keeping up — see What Is a DNS SOA Record.

Glue Records and Secondary Nameservers

Glue comes up most often when people add a second nameserver under their own domain. Two setups, two different answers:

Secondary under the provider's hostname. Your zone is delegated to ns1.example.com (your server) and to the secondary provider's own name, such as ns3.seconddns.com. Only ns1 is in-bailiwick, so only ns1 needs glue. Nothing changes at the registrar when the provider's addresses change.

Secondary under your own hostname — a personalized or vanity nameserver such as ns2.example.com pointing at the provider's server. Now ns2 is in-bailiwick too, and it needs glue with the provider's IP address. You add it at the registrar exactly like ns1, and you must keep it current: if the provider ever changes that address, the glue has to follow. You also need the matching A record for ns2.example.com in your own zone, which then travels to the secondary with every zone transfer.

This is the step most often skipped when setting up branded nameservers, and the reason a secondary that is perfectly in sync still does not receive queries. For the complete setup — hostname, glue, A records, and verification — see Personalized Nameservers: Setup, Glue Records, and Pitfalls.

Common Mistakes

- Editing the A record but not the glue after a server move. Update both, and check the parent with dig afterwards. - Adding glue for out-of-bailiwick names. Most registrars reject it; those that accept it publish data the parent will never use. Register only names under the domain itself. - Glue with a private or wrong IP. Registrars validate little; a typo goes live at the registry. Verify with a query to the TLD servers, not just to your own nameserver. - Forgetting IPv6. If your nameserver has an AAAA record, register the IPv6 glue too, or IPv6-only resolvers cannot reach it. - Expecting immediate effect. Large gTLD registries publish changes within minutes, while some ccTLDs regenerate their zone hourly or a few times a day — and resolvers cache the previous delegation for up to the parent's TTL — commonly 48 hours for .com. Plan nameserver IP changes with overlap: keep the old address answering until the caches expire. - Only one in-bailiwick nameserver with glue. If ns1 has glue and ns2 (also in-bailiwick) does not, the zone works only as long as ns1 is up — which defeats the purpose of having two.