What is a glue record and why is it required?

A glue record is an A or AAAA record for a nameserver that the parent zone publishes alongside a delegation, so resolvers can find the nameserver's IP address without first having to look it up inside the very zone it serves. It's required when a domain's nameservers live inside that domain, for example when example.com uses ns1.example.com. Without glue, a resolver would need to ask ns1.example.com for its own address, which it can't reach without already knowing that address. Glue breaks that circular dependency.

Most people never touch glue directly because their DNS provider's nameservers live in someone else's domain. But if you run your own nameservers, set up branded nameservers, or change the IP address of a server that acts as a nameserver, glue becomes something you have to understand and maintain. This article explains what glue is, when it's needed and when it isn't, how to see it with dig, where it's managed, and the problems that stale or missing glue causes.

The Problem Glue Solves

DNS works by delegation. The .com zone doesn't hold the records for example.com. Instead, it holds NS records that say which nameservers are authoritative for example.com, and resolvers follow that referral.

An NS record contains a hostname, not an IP address:

example.com.    172800  IN  NS  ns1.example.net.
example.com.    172800  IN  NS  ns2.example.net.

To contact ns1.example.net, a resolver first has to resolve that hostname to an IP address. That's fine here, because example.net is a separate domain with its own delegation. The resolver goes off, resolves ns1.example.net, and comes back.

Now imagine the nameservers are inside the domain they serve:

example.com.    172800  IN  NS  ns1.example.com.
example.com.    172800  IN  NS  ns2.example.com.

To find the address of ns1.example.com, the resolver has to ask the authoritative nameservers for example.com. Those are ns1.example.com and ns2.example.com, whose addresses it doesn't know. It's stuck in a loop.

Glue solves this by having the .com servers include the nameservers' addresses directly in the referral:

; Delegation in the .com zone
example.com.        172800  IN  NS    ns1.example.com.
example.com.        172800  IN  NS    ns2.example.com.

; Glue records in the .com zone
ns1.example.com.    172800  IN  A     192.0.2.53
ns1.example.com.    172800  IN  AAAA  2001:db8::53
ns2.example.com.    172800  IN  A     198.51.100.53

The resolver now has everything it needs in one response: the names of the nameservers and the IP addresses to reach them.

When Glue Is Required and When It Isn't

Whether glue is needed depends on where the nameserver's name sits relative to the zone being delegated.

Nameserver for example.com	Glue needed?	Why
ns1.example.com	Yes	The name is inside the delegated zone (in-domain)
ns1.sub.example.com	Yes	Still inside example.com
ns1.example.net	No	Resolvable via its own delegation
ns-123.awsdns-45.org	No	A completely separate domain
dana.ns.cloudflare.com	No	A completely separate domain

The two common terms you'll see are:

• In-domain (in-bailiwick) nameservers: The nameserver name is at or below the delegated zone, like ns1.example.com for example.com. Glue is mandatory, because there's no other way to resolve it.
• Out-of-domain nameservers: The nameserver name is in a different zone, like ns1.example.net for example.com. Glue isn't needed, and parents generally don't publish it.

There's a middle case called sibling glue, where the nameserver is in a different domain under the same parent, such as ns1.example.net used for example.org when both are handled by the same registry. Some registries publish it, but resolvers shouldn't depend on it, and it can mask problems if the sibling domain's own records change.

RFC 9471, published in 2023, tightened the rules for authoritative servers: when a referral involves in-domain nameservers, the parent must include all available glue for them, and set the truncation bit if it can't fit, so the resolver retries over TCP. That reflects how important glue is to resolution actually working.

Seeing Glue with dig

You can see glue by asking a TLD server directly, without recursion. First find the .com servers:

dig +short com NS | head -3

a.gtld-servers.net.
b.gtld-servers.net.
c.gtld-servers.net.

Then ask one of them about your domain with recursion turned off:

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

For a domain with in-domain nameservers, the referral looks like this:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20513
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4

;; 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     192.0.2.53
ns1.example.com.    172800  IN  AAAA  2001:db8::53
ns2.example.com.    172800  IN  A     198.51.100.53

There are a few things to notice:

• No aa flag: The TLD server isn't authoritative for example.com. It's handing out a referral.
• The NS records are in the AUTHORITY section, not the ANSWER section.
• The glue is in the ADDITIONAL section: Those A and AAAA records are the glue.

For a domain using out-of-domain nameservers, the additional section will be empty (apart from the OPT pseudo-record that dig shows when EDNS is used), because there's nothing to glue.

You can also watch glue being used during a full resolution with +trace:

dig example.com A +trace

Each referral step in the trace shows the NS records returned by the parent. When the next step goes straight to ns1.example.com with no separate lookup, it's using glue.

Glue Is Not Authoritative Data

This is an important subtlety. Glue lives in the parent zone, but the authoritative copy of ns1.example.com's address lives in your zone. They're two separate records that should match, but nothing automatically keeps them in sync.

# What the parent says (glue)
dig @a.gtld-servers.net ns1.example.com A +norec

# What your zone says (authoritative)
dig @192.0.2.53 ns1.example.com A +norec

If the answers differ, you have a glue mismatch. Resolvers use glue to make the first contact, then many prefer the authoritative answer once they have it. A mismatch means some resolvers try the old address and some try the new one, giving inconsistent and hard-to-debug results.

The reverse is also true. Updating the A record for ns1.example.com in your zone does not update the glue at the TLD. You have to change it at your registrar.

Where Glue Is Managed

Glue isn't edited in your DNS zone. It's managed by your registrar, which passes it to the TLD registry. Registries call these host objects: a nameserver hostname registered together with one or more IP addresses.

Registrars label this feature in different ways, so look for terms like:

• Register nameserver or Create host
• Child nameservers or Private nameservers
• Glue records or Host records
• Personal DNS servers

The process is generally:

1. Log in to the registrar where the parent domain (example.com) is registered.
2. Find the host or glue section and create ns1.example.com with its IPv4 and, ideally, IPv6 address.
3. Repeat for ns2.example.com.
4. Set the domain's nameservers to ns1.example.com and ns2.example.com.
5. Make sure your zone also contains matching A and AAAA records for those names.

Two rules apply at the registry level:

• You can only create a host object under a domain you control at that registrar: You can't register ns1.example.com unless you manage example.com.
• Hosts that are in use can't be deleted: If other domains use ns1.example.com as a nameserver, the registry will refuse to delete the host until those delegations are changed.

Updating Glue When a Nameserver's IP Changes

Moving a self-hosted nameserver to a new IP is where glue causes the most outages. The .com and .net glue records have a TTL of 172,800 seconds (two days), so resolvers may keep using the old address for up to 48 hours after you update it. A safe order is:

1. Bring up the nameserver on the new IP while the old one keeps running, serving identical zone data.

2. Update the A/AAAA record for ns1.example.com in your own zone.

3. Update the glue at your registrar for ns1.example.com.

4. Verify the TLD has the new glue:

   dig @a.gtld-servers.net ns1.example.com A +norec +short
   

5. Keep the old IP answering for at least two to three days, until cached referrals have expired.

6. Check the old server's query logs and only shut it down once queries have dropped away.

Doing one nameserver at a time keeps the other one fully reachable throughout, so even resolvers with stale glue for one server can still resolve your domain.

Common Glue Problems

Missing Glue

If your domain is delegated to ns1.example.com but no host object with an address exists, resolvers get a referral they can't follow. The usual symptom is SERVFAIL from public resolvers for every name in your zone:

dig @1.1.1.1 example.com A

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7741

The fix is to create the host objects at your registrar.

Stale Glue

Glue pointing at an IP that no longer runs a nameserver causes timeouts and slow resolution, or outright failure if all glue is stale. Compare glue with your authoritative records, as shown earlier, after any infrastructure change.

IPv4 Only

Many people register only IPv4 glue. That works, but IPv6-only resolvers and networks can't reach your nameservers. If your nameservers have IPv6 addresses, register AAAA glue too.

Both Nameservers in One Place

Glue makes it easy to point ns1 and ns2 at two IPs on the same server or in the same data centre. That technically satisfies the "two nameservers" requirement but gives you no real redundancy. Put them on separate networks, ideally with different providers.

Checking Glue with a Script

If you manage several domains with self-hosted nameservers, a small script can compare glue with authoritative data. This one uses the dnspython library (pip install dnspython):

import dns.flags
import dns.message
import dns.query
import dns.rdatatype
import dns.resolver

TLD_SERVER = "192.5.6.30"  # a.gtld-servers.net
DOMAIN = "example.com"

query = dns.message.make_query(DOMAIN, "NS")
query.flags &= ~dns.flags.RD  # no recursion
response = dns.query.udp(query, TLD_SERVER, timeout=5)

glue = {}
for rrset in response.additional:
    if rrset.rdtype in (dns.rdatatype.A, dns.rdatatype.AAAA):
        glue.setdefault(rrset.name.to_text(), set()).update(r.address for r in rrset)

for name, glue_ips in glue.items():
    auth_ips = set()
    for rdtype in ("A", "AAAA"):
        try:
            auth_ips.update(r.address for r in dns.resolver.resolve(name, rdtype))
        except (dns.resolver.NoAnswer, dns.resolver.NXDOMAIN):
            pass
    status = "OK" if glue_ips == auth_ips else "MISMATCH"
    print(f"{status:9} {name} glue={sorted(glue_ips)} zone={sorted(auth_ips)}")

if not glue:
    print("No glue in referral (nameservers are probably out-of-domain)")

192.5.6.30 is the IPv4 address of a.gtld-servers.net, which serves .com and .net. For other TLDs, look up that TLD's nameservers with dig TLD NS first.

---

FAQ: Glue Records

---

Conclusion

A glue record is the IP address of an in-domain nameserver, published by the parent zone so resolvers can reach it without a circular lookup. It's mandatory when example.com uses nameservers like ns1.example.com, and unnecessary when your nameservers live in a separate domain, which is the case for almost every managed DNS provider.

If you do rely on glue, remember that it's managed at your registrar, not in your zone, and that it doesn't update itself. Check it with dig against a TLD server whenever you change a nameserver's address, keep the old IP answering until cached referrals expire, and put your nameservers on separate networks so a single failure can't take your domain offline.