A glue record is an A or AAAA record for a nameserver that is stored in the parent zone, right next to the delegation, instead of only in the child zone it belongs to. Glue exists to break a chicken-and-egg problem that would otherwise make certain domains impossible to resolve. If your domain's nameservers are named inside your own domain, a resolver would need to reach your nameservers to find their addresses, but it needs those addresses to reach them in the first place. Glue cuts that loop.
The circular dependency, step by step
Say you run example.com and your nameservers are ns1.example.com and ns2.example.com. A resolver that wants a record in your zone starts at the .com servers and asks who is authoritative for example.com. The .com servers reply with a referral: "ask ns1.example.com or ns2.example.com."
Now the resolver is stuck. To send a query it needs the IP address of ns1.example.com. But ns1.example.com is itself inside example.com, the very zone it is trying to reach. The only place that knows the address is the server it cannot yet contact.
Resolver -> .com servers: "Who serves example.com?"
.com servers -> resolver: "ns1.example.com and ns2.example.com"
Resolver: "...but what is the IP of ns1.example.com?"
(it lives inside example.com -- deadlock)The parent zone solves this by shipping the nameserver's IP address along with the referral. The .com zone stores an A record for ns1.example.com as glue, and includes it in the additional section of the referral response. Now the resolver has both the name and the address and can continue.
In-bailiwick vs out-of-bailiwick
Glue is only required when a nameserver's name falls inside the domain it serves. The jargon for that is "in-bailiwick." If your nameservers live under a different domain, no glue is needed, because the resolver can look up their addresses independently through normal resolution.
| Scenario | Nameserver name | Glue needed? |
|---|---|---|
| In-bailiwick | ns1.example.com for example.com | Yes, parent must publish glue |
| Out-of-bailiwick | ns1.hostingprovider.net for example.com | No, resolved normally |
| Partly in-bailiwick | ns1.example.com and ns1.other.net | Glue needed for the in-bailiwick one |
This is why using your DNS provider's own nameservers (for example amy.ns.cloudflare.com) avoids the whole glue question: those names are out-of-bailiwick for your domain and resolve on their own. You only deal with glue when you run vanity nameservers on your own domain.
Seeing glue in a real query
Query the parent directly with +norecurse to watch the referral and its additional section. The glue appears below the authority section.
$ dig @a.gtld-servers.net example.com NS +norecurse
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 172800 IN A 199.43.135.53
a.iana-servers.net. 172800 IN AAAA 2001:500:8f::53The records in the additional section are the glue. When you trace a delegation with a name that is in-bailiwick, you will see the glue A and AAAA records for those in-domain nameservers right there in the referral, supplied by the parent so resolution can proceed.
Where glue actually comes from
Here is the part that trips people up: glue records are not something you put in your own zone file. They live in the parent zone, so they are created and maintained through your registrar, which pushes them to the registry that runs the parent (for example Verisign for .com). Registrars usually expose this under a feature called "register a host," "private nameservers," "host records," or "glue records."
- You register a host object, for example
ns1.example.com, and assign it an IP address. - The registrar sends that host and its address to the registry.
- The registry publishes it as glue in the parent zone.
- You then set your domain's nameservers to
ns1.example.comandns2.example.com.
You still keep matching A and AAAA records for the same names inside your own zone, so both the parent's glue and your authoritative zone agree. Inconsistency between the two is a common and confusing failure, because resolvers may use either source and will behave differently depending on which answer they cached first. Whenever you touch a nameserver address, change it in both places and treat them as a single unit.
Common glue problems
- Missing glue. You set in-bailiwick nameservers but never registered the host objects. Resolution breaks because the referral has names but no addresses.
- Stale glue. You changed a nameserver's IP in your zone but forgot to update the host object at the registrar. The parent hands out an old address and queries go nowhere, or worse, to someone else.
- Glue for the wrong family. You added an A glue but no AAAA, so IPv6-only resolvers cannot reach the nameserver. Publish both where you support both.
- Orphaned glue. A host object left behind after you stop using a nameserver. It is harmless day to day but worth cleaning up, and in some abuse cases dangling glue has security implications.
Glue and nameserver changes
When you renumber a vanity nameserver, treat glue as the source of truth that the outside world uses. Update the host object at the registrar first, confirm the parent is handing out the new address, and only then retire the old IP. Because the parent's glue often carries a long TTL (172800 seconds, two days, is common for .com), plan for the change to take time to clear from caches everywhere.
Do you even need vanity nameservers?
For most people the honest answer is no. Vanity nameservers like ns1.yourbrand.com look polished and keep your branding consistent, but they add the glue maintenance burden and another place for things to drift. Unless branding or multi-tenant requirements justify it, using your DNS provider's out-of-bailiwick nameservers is simpler and removes glue from your worry list entirely.
Verify the delegation holds together
Glue problems are quiet until they are catastrophic, because a broken delegation can take an entire domain offline. After you register or change a host object, confirm that the parent is serving the correct glue and that your own zone agrees. You can check that your nameservers and their addresses resolve consistently across the internet with the Valla DNS propagation checker, and the Valla DNS /learn/ guides on the SOA record and registrar transfers cover the neighboring pieces of delegation you will touch along the way.