What Are Glue Records, and Why Are They Needed?

Suppose you run your own nameservers and want them to be called ns1.example.com and ns2.example.com. You log in to your registrar, set those as the nameservers for example.com, and the registrar rejects the change, or accepts it and the domain stops resolving entirely. The missing piece is a glue record. Glue is one of those DNS details most people never need to think about, until the day they set up self-hosted or vanity name servers and suddenly it is the only thing that matters. This article explains the chicken-and-egg problem glue solves, where glue records live, how to check and create them, and the mistakes that cause outages. For background on how delegation works in general, see What Is an NS Record, and How Does It Delegate a Domain?

What Is a Glue Record?

A glue record is an A or AAAA record for a nameserver, published in the parent zone alongside the NS delegation, so that resolvers can find the nameserver's IP address without first querying the very zone it serves.

For example.com, the parent zone is com, operated by the .com registry. When you register nameservers called ns1.example.com and ns2.example.com, the registry publishes their IP addresses in the com zone. Those addresses are the glue.

Glue is not authoritative data. The com servers are not the source of truth for ns1.example.com; your own zone is. Glue is a hint the parent hands out during referrals to make resolution possible.

The Chicken-and-Egg Problem

Here is why glue is necessary. Walk through resolving www.example.com with nameservers inside the same domain and no glue:

1. The resolver asks a root server about www.example.com and is referred to the .com servers. (See What Are Root Name Servers? and What Are TLD Name Servers? for those steps.)
2. The resolver asks a .com server and is told "example.com is served by ns1.example.com and ns2.example.com."
3. To contact ns1.example.com, the resolver needs its IP address.
4. To find the IP of ns1.example.com, it has to ask the nameservers for example.com.
5. The nameservers for example.com are ns1.example.com and ns2.example.com. Go to step 3.

That loop never ends. Glue breaks it at step 2: the .com server includes the IP addresses of ns1.example.com and ns2.example.com in the additional section of its referral, so the resolver can contact them immediately.

When Glue Is Required and When It Is Not

Whether a delegation needs glue depends on where the nameserver names live relative to the zone being delegated. RFC 9471 (2023) uses these terms:

Nameserver for example.com	Relationship	Glue in com zone?
ns1.example.com	In-domain (in-bailiwick)	Required — resolution is impossible without it
ns1.example-dns.com	Sibling domain (same parent zone, different domain)	Optional but commonly included
ns1.example-dns.net	Out-of-bailiwick (different TLD)	Not used — resolver looks it up separately

1. In-domain nameservers (names under the domain being delegated) always need glue. Without it there is a circular dependency.
2. Sibling nameservers live in the same parent zone but under a different domain, such as ns1.example-dns.com serving example.com. Glue is not strictly required because the resolver can resolve example-dns.com separately, but registries often have it on file, and RFC 9471 says it should be included in referrals when available, to avoid extra lookups and some failure cases.
3. Out-of-bailiwick nameservers, like a managed DNS provider's servers under a different TLD, do not get glue. The resolver starts a separate lookup for the nameserver's address.

This is why using a managed DNS provider such as ns1.example-dns.net never involves glue for you: the provider has already registered glue for their own domain, under their own parent zone.

What Glue Looks Like on the Wire

You can see glue directly by asking a .com server for a delegation, with recursion turned off so you see the referral itself:

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

A delegation with in-domain nameservers returns something like this:

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5

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

;; ADDITIONAL SECTION:
ns1.example.com.    172800  IN  A     203.0.113.53
ns2.example.com.    172800  IN  A     198.51.100.53
ns1.example.com.    172800  IN  AAAA  2001:db8::53
ns2.example.com.    172800  IN  AAAA  2001:db8:1::53

Three things to note:

• The answer section is empty, and the aa (authoritative answer) flag is absent, because this is a referral rather than an answer.
• The authority section holds the NS records for the delegation.
• The additional section holds the glue: A and AAAA records for the in-domain nameservers. (The fifth additional record, not shown, is the EDNS OPT pseudo-record.)

If you run the same query for a domain hosted on a managed provider under another TLD, the additional section will contain no address records for those nameservers. More on this kind of query is in How to Use the dig Command for DNS Lookups.

To find the right TLD server to query for other extensions, look up the TLD's own NS records first:

dig org NS +short

Pick any server from the output and use it with @ in the earlier command.

Glue in the Zone File

On the parent side, glue is just address records below a delegation point. Here is how a simplified parent zone would express a delegation with glue. You would see the same pattern in your own zone if you delegate a subdomain to nameservers inside that subdomain:

; In the example.com zone, delegating dev.example.com
dev        IN  NS    ns1.dev.example.com.
dev        IN  NS    ns2.dev.example.com.
ns1.dev    IN  A     203.0.113.80
ns2.dev    IN  A     198.51.100.80

The NS records delegate dev.example.com. The two A records are glue, because the nameservers are inside the delegated subzone. Without them, nobody could find the servers for dev.example.com.

Your own zone (example.com) must also contain authoritative A and AAAA records for its nameservers, and they must match the glue at the registry:

$ORIGIN example.com.
@     IN  NS    ns1.example.com.
@     IN  NS    ns2.example.com.
ns1   IN  A     203.0.113.53
ns1   IN  AAAA  2001:db8::53
ns2   IN  A     198.51.100.53
ns2   IN  AAAA  2001:db8:1::53

These are the authoritative versions of the same addresses. Resolvers use the glue to reach your servers, then usually trust your authoritative records from then on.

How to Create Glue Records at Your Registrar

You cannot create glue in your own zone file for your own domain, because the glue lives in the parent zone, which only the registry controls. You register it through your registrar, which passes it to the registry as a host object.

Registrars label this feature inconsistently. Look for:

• "Register nameservers" or "Register a nameserver"
• "Child nameservers" or "Personal nameservers"
• "Host records" or "Glue records"
• "Private nameservers"

The process is usually:

1. Create the host. Enter ns1.example.com with its IPv4 address, and IPv6 if available. Repeat for ns2.
2. Wait for the registry to accept it. This is typically quick, but some registries take longer.
3. Change the domain's nameservers to ns1.example.com and ns2.example.com. Most registrars will refuse this step if the host objects do not exist yet, which is the error you hit at the start.
4. Make sure your servers answer authoritatively for example.com before switching, and that their zone contains matching A and AAAA records.

The nameserver change workflow itself is covered in How to Update Nameservers for the Domain. If you are standing up the servers yourself, How to Run Your Own DNS Server with BIND walks through it.

Common Glue Mistakes

1. Changing a nameserver's IP without updating glue. This is the classic glue outage. You move ns1.example.com to a new server and update the A record in your zone, but the registry still hands out the old IP in referrals. Resolvers follow the glue to a dead address. Always update the host object at the registrar when a nameserver's IP changes.
2. Mismatched glue and zone data. Glue says one IP, your zone says another. Some resolvers will use one, some the other, leading to inconsistent behaviour that is hard to reproduce.
3. Missing IPv6 glue. If your nameservers have IPv6 but the registry only holds IPv4 glue, IPv6-only resolvers fall back to extra lookups or fail. Register both.
4. Forgetting other domains depend on the host. If ns1.example.com also serves example.org and others, a stale glue record for it at the .com registry affects every domain that uses it.
5. Trying to delete a host still in use. Registries usually refuse to delete a host object that other domains still reference. Move those domains first.
6. Both nameservers on one network. Not strictly a glue problem, but common with self-hosted setups: two IPs in the same subnet give you no real redundancy.

To verify your glue against your zone, compare the two directly:

# What the registry hands out
dig @a.gtld-servers.net example.com NS +norecurse | grep -E "IN[[:space:]]+(A|AAAA)"

# What your own nameserver says
dig @203.0.113.53 ns1.example.com A +short
dig @203.0.113.53 ns2.example.com A +short

The first command extracts just the glue lines from the referral. The next two ask your nameserver directly for the authoritative addresses. They should match exactly.

Glue and Security

Because glue is unsigned hint data, DNSSEC does not cover it. DNSSEC protects the records you get from your authoritative servers, and the DS record in the parent links the chain, but a resolver following glue to the wrong IP will simply fail validation rather than be fooled. That makes stale glue an availability problem rather than an integrity one, provided your zone is signed. Registrar account security matters here too: anyone who can change your host objects can redirect your nameservers. See What Is Registrar Lock?

---

Glue Records FAQ

Conclusion

Glue records exist to solve one specific problem: a domain whose nameservers are named inside the domain itself. Without the parent zone handing out their IP addresses, resolvers would be stuck in an endless loop trying to find the servers they need to ask. With glue, the referral from the TLD carries everything a resolver needs to continue.

If you use a managed DNS provider, glue is handled for you and you can safely ignore it. If you run your own or vanity nameservers, glue becomes part of your operational checklist: register host objects at your registrar before switching, include both IPv4 and IPv6, keep glue identical to your zone data, and update it every time a nameserver's IP changes. Those few habits prevent one of the most confusing kinds of DNS outage.

Here are some useful references for going deeper on glue records:

1. RFC 9471: DNS Glue Requirements in Referral Responses — defines in-domain and sibling glue and when servers must include them.
2. RFC 1034: Domain Names - Concepts and Facilities — the original description of delegation and glue.
3. RFC 5732: Extensible Provisioning Protocol (EPP) Host Mapping — how registrars register nameserver host objects with registries.
4. Cloudflare Learning Center: What is a DNS NS record? — background on NS delegation that glue supports.
5. BIND 9 Documentation: BIND 9 Administrator Reference Manual — configuring authoritative zones and delegations.