Glue records have a reputation for being obscure, and they are — right up until the moment a domain stops resolving for everyone on earth and nothing in the zone file looks wrong. Glue is a small exception carved into the DNS delegation model to solve exactly one problem: a nameserver whose name cannot be looked up without first reaching that nameserver. This guide explains the problem, the fix, where the data actually lives, and how to tell whether yours is correct.
What Is a DNS Glue Record?
A glue record is an A or AAAA record for a nameserver hostname that is published by the parent zone, alongside the delegation, rather than by the zone the hostname belongs to.
That one sentence contains the whole idea, but the important half is easy to skim past: published by the parent. A normal A record for www.example.com lives in the example.com zone, on your nameservers, under your control. A glue record for ns1.example.com lives in the .com zone, on Verisign's servers, and gets there through your registrar. It is the same record type carrying the same IP address, in a completely different place, owned by somebody else.
Glue is not a separate record type. There is no GLUE in the DNS protocol. "Glue" describes a role: an address record that appears in the additional section of a referral because the resolver is about to need it and has no other way to get it.
Glue is the parent zone telling a resolver "go ask ns1.example.com — and by the way, since you have no way of finding that name on your own, here is its IP address."
The Circular Dependency Glue Solves
DNS delegation works by handing a resolver the names of the next servers to ask. NS records contain hostnames, never IP addresses — that indirection is deliberate, because it lets a DNS provider renumber its servers without every domain in the world having to be updated. See What Is an NS Record? for how delegation is structured.
Handing over a name works fine as long as the resolver can look that name up. Follow what happens when it cannot. Suppose example.com is served by nameservers you run yourself, named ns1.example.com and ns2.example.com:
Resolver: .com servers, where is www.example.com?
.com: I do not know, but example.com is served by ns1.example.com.
Resolver: fine — what is the IP address of ns1.example.com?
.com: I do not know that either. example.com is served by ns1.example.com.
Resolver: ...which I cannot reach, because I do not know its address.
.com: example.com is served by ns1.example.com.
↻ deadlockThe resolver is stuck in a loop. To learn the address of ns1.example.com it must query the authoritative server for example.com, which is ns1.example.com. The information needed to reach the server is only available from the server itself.
Glue breaks the loop by having the parent publish the address directly. The .com zone cannot claim authority over ns1.example.com — that name belongs to your zone — but it can include the address as a hint in the referral, which is all the resolver needs to make first contact. With glue in place the conversation becomes a single exchange:
Resolver: .com servers, where is www.example.com?
.com: Ask ns1.example.com — it is at 198.51.100.10.
└──────┬──────┘
the glue record
Resolver: (connects to 198.51.100.10) where is www.example.com?
ns1: 203.0.113.25 ← authoritative answer, aa flag setWhen You Need Glue — and When You Do Not
This is the part people get wrong in both directions: adding glue that does nothing, or leaving out glue that is mandatory. The rule depends entirely on where the nameserver hostname sits relative to the domain it serves. The DNS terminology RFC (RFC 9499, which replaced RFC 8499) gives the three cases names.
| Case | Example for example.com | Glue? | Why |
|---|---|---|---|
| In-domain | ns1.example.com | Required | Circular — the name can only be resolved by the server it names |
| Sibling domain | ns1.example-dns.com | Optional | Different zone, same parent — the TLD happens to hold the address, so it may include it |
| Out-of-zone | ns1.cloudflare.com for example.net | Impossible | The parent has no knowledge of that name; the resolver looks it up separately |
The overwhelming majority of domains fall into the third row and need no glue at all. If you use Cloudflare, Route 53, Google Cloud DNS or your registrar's bundled DNS, your nameservers are named after their domain, not yours, and the whole question is moot. Glue becomes your problem the moment you decide to run branded nameservers — ns1.yourdomain.com — which is exactly when it is least expected.
All three cases in one real referral
You do not have to take this on faith. Ask a .com TLD server about github.comand read which nameservers get an address and which do not:
$ dig +norecurse @a.gtld-servers.net github.com NS
;; AUTHORITY SECTION:
github.com. 172800 IN NS ns-520.awsdns-01.net.
github.com. 172800 IN NS ns-421.awsdns-52.com.
github.com. 172800 IN NS ns-1707.awsdns-21.co.uk.
github.com. 172800 IN NS ns-1283.awsdns-32.org.
github.com. 172800 IN NS dns1.p08.nsone.net.
github.com. 172800 IN NS dns2.p08.nsone.net.
github.com. 172800 IN NS dns3.p08.nsone.net.
github.com. 172800 IN NS dns4.p08.nsone.net.
;; ADDITIONAL SECTION:
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
ns-421.awsdns-52.com. 172800 IN AAAA 2600:9000:5301:a500::1Eight nameservers, one address. Only ns-421.awsdns-52.com is a sibling — it lives under .com, the same parent zone that holds the github.com delegation, so the registry is able to include its address. The .net, .org and .co.uk nameservers are out of zone; .com knows nothing about them and says nothing. Resolution still works perfectly, because the resolver can look those names up the ordinary way.
Contrast that with a domain whose nameservers are in-domain. Google runs its own, so every one of them must be glued:
$ dig +norecurse @a.gtld-servers.net google.com NS
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 172800 IN A 216.239.32.10
ns1.google.com. 172800 IN AAAA 2001:4860:4802:32::a
ns2.google.com. 172800 IN A 216.239.34.10
ns2.google.com. 172800 IN AAAA 2001:4860:4802:34::a
ns3.google.com. 172800 IN A 216.239.36.10
ns3.google.com. 172800 IN AAAA 2001:4860:4802:36::a
ns4.google.com. 172800 IN A 216.239.38.10
ns4.google.com. 172800 IN AAAA 2001:4860:4802:38::aPlenty of healthy domains show no glue whatsoever. showdns.net is delegated to alec.ns.cloudflare.com and athena.ns.cloudflare.com, so the .net referral carries the two NS records and nothing else — the addresses come from .com on a separate lookup. Before calling missing glue a bug, check whether the nameserver is even inside the domain.
Where Glue Records Actually Live
Four properties follow from glue living in the parent zone, and every one of them trips somebody up eventually.
1. You cannot publish glue from your own zone
Adding an A record for ns1.example.com in your DNS control panel does not create glue. It creates a perfectly valid authoritative record that no resolver can reach yet, because reaching it requires the very server it describes. Glue has to come from the layer above, which means it has to be entered at your registrar — the only party with a channel to the registry.
2. It is a hint, not an authoritative answer
The .com servers are not authoritative for ns1.example.com, so glue arrives without the aa flag and ranks low in a resolver's trust ordering. A resolver uses glue to make contact and then, in most implementations, re-asks your nameserver for the real A record and prefers that answer. Glue gets the resolver through the door; your zone furnishes the room.
3. The TTL is the registry's, not yours
Look at the TTL in those referrals: 172800 seconds — two days — set by the .com registry and identical for every domain. You cannot lower it the way you would lower the TTL on your own records before a migration. Meanwhile, the authoritative A record for ns1.google.com inside Google's zone carries a TTL of 345600. Same hostname, same address, two different TTLs from two different sources.
Because you do not control the parent TTL, a glue IP change is not a cutover — it is an overlap. Resolvers that cached the old referral will keep sending queries to the old address for up to 48 hours in .com and .net. Keep the old IP answering DNS for the full window, or a portion of the internet will simply stop resolving your domain until the cache expires.
4. It is not signed
The parent signs its own authoritative data — the DS record and the NSEC/NSEC3 proofs — but not the NS records of the delegation and not the glue. There is nothing for a validating resolver to check. This is fine by design: glue only has to be good enough to reach a server, and everything that server subsequently says is signed by your zone and validated there. See What Is DNSSEC?.
Glue Records vs the A Records in Your Zone
A rule that sounds contradictory but is not: if your nameservers are in-domain you need both the glue at the registrar and matching A/AAAA records inside your own zone. They are not duplicates of each other.
| Glue record | A record in your zone | |
|---|---|---|
| Stored in | The parent TLD zone | Your zone file |
| Edited at | Your registrar | Your DNS host |
| Authority | Non-authoritative hint | Authoritative, aa flag set |
| TTL set by | The registry | You |
| Signed by DNSSEC | No | Yes, if the zone is signed |
| Purpose | Get the resolver to your server the first time | Be the correct, lasting answer for the hostname |
A zone running its own nameservers therefore looks like this internally, with the NS records naming the servers and the A records giving them addresses:
; example.com zone file (abridged)
$TTL 3600
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
; these must exist, and must match the glue at the registrar
ns1.example.com. IN A 198.51.100.10
ns2.example.com. IN A 198.51.100.20
ns1.example.com. IN AAAA 2001:db8:1::10
ns2.example.com. IN AAAA 2001:db8:1::20
example.com. IN A 203.0.113.25
www.example.com. IN CNAME example.com.If the glue says 198.51.100.10 and the zone says 198.51.100.99, you have a mismatch that behaves erratically: resolvers that make first contact via glue reach one machine, then cache the zone's A record and reach a different one on the next pass. Diagnosing that from the symptoms alone is miserable. Compare the two directly instead.
How to Check Your Glue Records
Ask the TLD server
The definitive check. Query a TLD server for your domain's NS records with recursion disabled and read the additional section — whatever appears there is your glue, exactly as every resolver on the internet receives it.
# .com and .net domains
dig +norecurse @a.gtld-servers.net example.com NS
# any TLD — find its servers first, then ask one
dig NS org.
dig +norecurse @a0.org.afilias-nst.info example.org NS
# just the addresses, no noise
dig +norecurse +noall +additional @a.gtld-servers.net example.com NSWalk the whole chain
dig +trace starts at the root and follows every referral, printing each step. The glue shows up as the address records in the TLD's response, and you get to see whether the walk completes at all — which is the fastest way to spot a delegation that dead-ends.
dig +trace example.com
# Windows has no dig by default; nslookup can query the TLD directly
nslookup -type=ns example.com a.gtld-servers.netCheck the registry's view
Registries store glue as host objects — named records with addresses attached, created over EPP by your registrar and referenced by every domain that uses them. A WHOIS query on the nameserver hostname, rather than the domain, shows the object as the registry holds it:
whois ns1.example.com # the host object and its registered IPs
whois example.com | grep -i "name server"Use the browser tools
NS Lookup queries the parent TLD and your zone separately, lists the address each nameserver resolves to, and flags the case that matters most: a delegation where the parent and the zone no longer publish the same NS set. DNS Health Check runs the same delegation checks as part of a wider audit, and WHOIS Lookup shows the nameservers recorded at the registrar.
How to Add or Change a Glue Record
Glue is created at the registrar, and every registrar names the feature differently. Look for Child Nameservers, Host Records, Register a Nameserver, Private Nameservers, Personal Nameservers or Glue Records — all the same EPP host object underneath.
The order of operations matters more than the clicking. Doing this out of sequence is the classic way to take a domain offline:
- Build and test the nameservers first. Query them by IP before anything is delegated to them:
dig @198.51.100.10 example.com SOAmust return your zone with theaaflag. - Put the A/AAAA records for the nameserver hostnames in the zone. Glue that has no authoritative counterpart is a half-configured delegation.
- Register the host objects at the registrar. Create
ns1.example.comandns2.example.comwith their addresses. This is the step that writes the glue into the TLD zone. - Point the domain at them. Only now change the domain's nameservers to the hosts you just registered.
- Verify from the parent. Re-run the
dig +norecursecheck above and confirm the referral carries both the NS records and the addresses.
Renumbering ns1.example.com means updating the glue at the registrar and the A record in your zone. Change only the zone and resolvers keep arriving at the old address from the parent referral for up to two days. Change only the glue and your own zone contradicts the parent. Do both, then keep the old IP live through the parent TTL.
What Breaks When Glue Is Wrong
Glue failures produce distinctive symptoms. Matching the symptom to the cause saves a great deal of guessing.
| Problem | What you see | Cause |
|---|---|---|
| Missing glue | SERVFAIL everywhere; the domain resolves for nobody | In-domain nameservers with no host objects registered |
| Stale glue | Worked before a server move, broken since; recovers after ~48h | Nameserver renumbered in the zone but not at the registrar |
| Glue / zone mismatch | Intermittent, resolver-dependent, some records look old | Parent hint and authoritative A record disagree |
| Partial glue | Slow lookups, occasional timeouts, works on retry | Only some in-domain nameservers have host objects |
| Lame delegation | Glue is present and correct, queries still fail | The address is right but the server is not serving the zone |
| Orphan glue | Registrar refuses to delete a nameserver or transfer a domain | Other domains still reference the host object |
The two worth dwelling on are the two that are easy to misread.
Missing glue is total, not partial. It does not degrade performance or affect one region — every resolver in the world hits the same dead end. If a domain with in-domain nameservers resolves for anyone, the glue is almost certainly present and your problem lies elsewhere.
Stale glue looks like a caching problem because it is one — just not a cache you can flush. Users on resolvers that already hold the parent referral fail; users on resolvers that never cached it succeed. It self-heals in exactly the parent TTL, which is why "it fixed itself after two days" is such a strong signal that glue was the culprit. For the general shape of this problem see DNS Cache Explained and What Is DNS TTL?.
Glue, Response Size and RFC 9471
Glue is not free. Each address record adds bytes to a referral that was already carrying an NS set, and DNS over UDP has limits — 512 bytes without EDNS(0), commonly 1232 or 4096 with it. A domain with eight in-domain nameservers, each with an A and an AAAA record, produces a referral large enough to matter.
Historically, a server whose response would not fit could drop some glue and send what remained. That is a quiet trap: the resolver gets a referral naming servers it cannot reach and has no way to know anything was omitted. RFC 9471, published in 2023, closed the hole by requiring that if a server cannot include all the in-domain glue, it must set the truncation bit so the resolver retries over TCP and receives the complete answer.
Two authoritative nameservers is the practical minimum for redundancy; four is ample for almost everyone. Long lists of in-domain nameservers inflate every referral, push responses towards truncation and TCP retries, and buy very little resilience past the first few. Diversity of network and provider matters far more than count.
Summary
A glue record is an address record for a nameserver, published by the parent zone because the resolver has no other way to obtain it. It exists solely to break the circular dependency created when a domain's nameservers live inside the domain they serve. If your nameservers are named after somebody else's domain — and for most sites they are — glue is not part of your life. If they are named after yours, glue is load-bearing: without it the domain resolves for nobody at all.
Remember where it lives and who owns it. Glue is entered at the registrar, stored in the TLD zone, served without authority, unsigned, and carries a TTL you cannot change. That last property is the one that bites: two days of cached referrals in .com means every glue change needs an overlap window, not a cutover. Check it from the parent, keep it in step with the A records in your own zone, and it will stay the invisible plumbing it is supposed to be.
Frequently Asked Questions
1. What is a DNS glue record?
A glue record is an A or AAAA record for a nameserver hostname, stored at the parent zone alongside the delegation instead of inside the domain it belongs to. It exists to break a circular dependency: when the nameservers for example.com are named ns1.example.com and ns2.example.com, a resolver cannot look them up without already being able to reach them. The parent TLD publishes their IP addresses in the referral so the resolver has somewhere to go.
2. Do I need glue records for my domain?
Only if your nameserver hostnames sit inside the domain they serve. If you point example.com at ns1.cloudflare.com or ns-520.awsdns-01.net, no glue is needed or possible — the resolver can look those names up normally through .com and .net. If you run your own nameservers as ns1.example.com, glue is mandatory and your domain will not resolve at all without it.
3. Where are glue records stored?
In the parent zone, not in yours. For example.com that means the .com zone operated by Verisign, which received the data from your registrar. Glue does not live in your zone file and your DNS host cannot publish it for you. That is why glue is edited at the registrar (often labelled "child nameservers", "host records", "register a nameserver" or "private nameservers") rather than in your DNS control panel.
4. What is the difference between a glue record and an A record?
They can hold the same IP address but they live in different places and carry different authority. The glue record is a hint published by the parent registry to get a resolver to your nameserver; it is not authoritative. The A record in your own zone is the real, authoritative answer for that hostname. You need both, and they must agree — resolvers use the glue to make first contact and then trust your zone data over it.
5. How do I check my glue records?
Ask the TLD server directly and read the additional section: dig +norecurse @a.gtld-servers.net example.com NS. Any A or AAAA records that come back under ADDITIONAL are your glue. dig +trace example.com shows the same thing in the context of a full resolution walk. In the browser, NS Lookup reads the parent referral for you and shows the address each nameserver resolves to next to the delegation.
6. What happens if a glue record is missing?
If the nameserver is in-domain, resolution fails completely — the resolver is told to ask ns1.example.com, has no way to find ns1.example.com, and gives up with SERVFAIL. The domain does not resolve for anybody once caches expire. If the missing glue is for an out-of-zone nameserver such as ns1.cloudflare.com, nothing breaks at all; the resolver simply looks the name up separately.
7. How long does it take for a glue record change to take effect?
The registry usually pushes the change to the TLD zone within minutes, but resolvers that already cached the old referral keep it for the parent TTL — 172800 seconds, or two full days, in .com and .net. You cannot shorten that TTL because you do not control the parent zone. Plan every glue IP change with an overlap: keep the old address answering DNS for at least 48 hours after the change.
8. What is an orphan glue record?
It is a glue record left behind at the registry after the delegation that justified it is gone — the domain was deleted or repointed, but the host object for ns1.example.com still exists because other domains reference it. Orphan glue is a housekeeping problem and occasionally an abuse one, since it can keep resolving a nameserver name whose domain has been taken down. Registrars generally refuse to delete a host object while any domain still points at it.
9. Can glue records be signed with DNSSEC?
No. Glue is non-authoritative data in the parent zone, and the parent does not sign it — the only signed records in a delegation are the DS record and the NSEC/NSEC3 proof. A resolver therefore cannot validate glue. Security comes from what happens next: once the resolver reaches your nameserver, the answers it gets back are signed by your zone and can be validated normally.