DNS delegation tells recursive resolvers which authoritative name servers hold the answers for a domain. Usually, a resolver can look up the address of a delegated name server through ordinary DNS. A problem appears when the name server’s hostname is inside the very domain it serves: the resolver needs the domain’s authoritative server to find the server’s address, but it needs that address to reach the authoritative server.
DNS glue records break this circular dependency. The parent zone supplies the address information needed to contact the child name server along with the delegation. Glue is small, but incorrect or missing glue can make a correctly configured zone unreachable from parts of the Internet.
What is a DNS glue record?
A glue record is an A or AAAA address record placed in the parent-side delegation context for a child name server. It is not a separate DNS record type named “GLUE.” The term describes how the parent supplies address data that helps a resolver follow the referral to the child zone.
Consider a domain delegated to these servers:
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
Both name-server hostnames are inside example.com. Without their addresses, a resolver would have to ask the example.com authoritative servers where ns1.example.com is—but it cannot contact those servers until it knows the addresses. The parent zone avoids the loop by returning the NS referral plus A and, when configured, AAAA data for the child name servers.
This behavior belongs to the wider delegation process. The site’s DNS delegation guide explains how authority moves from a parent zone to a child. The ClouDNS article on DNS delegation provides another practical overview and appears here in the first half of this article.
When glue is required
In-bailiwick name servers
A name server is in-bailiwick when its hostname falls within the delegated namespace. For the delegation of example.com, ns1.example.com is in-bailiwick. The parent needs to provide its address as glue so a resolver can reach it without already resolving data from the child.
Out-of-bailiwick name servers
If example.com uses ns1.dns-provider.net, that server is outside the child domain. A resolver can follow the DNS hierarchy for dns-provider.net independently to find its address. The .com parent of example.com is not authoritative for that external hostname and generally does not need to supply glue for it.
This distinction is important because extra address data in a referral is not automatically authoritative. Resolvers apply bailiwick rules to decide which additional data can be accepted and cached safely.
Glue at the registrar and host records in the child zone
Operators commonly configure glue through a registrar feature named “child name server,” “host object,” “personal nameserver,” or “register nameserver.” This creates or updates the parent-side address association through the registry. It is different from merely adding an A or AAAA record in the domain’s own authoritative zone.
For an in-bailiwick server, both locations matter:
- Parent-side glue: Lets a resolver reach the child authoritative server during delegation.
- Child-zone A or AAAA record: Provides the authoritative address answer after the child server is reachable.
The values should be consistent. If the registry glue points to an old address while the child zone publishes a new one, resolvers may reach different servers depending on cached state and lookup path. Update both deliberately during a migration.
The article A record vs AAAA record explains the IPv4 and IPv6 address types used for name-server hostnames.
IPv4 and IPv6 glue
IPv4 glue uses A records, while IPv6 glue uses AAAA records. Publishing both can allow resolvers to reach authoritative service over either protocol, provided the DNS server and network actually work on both addresses.
Do not publish an IPv6 glue address merely because the server has an IPv6 interface. Test authoritative DNS over UDP and TCP on port 53 from outside the hosting network. A broken IPv6 path can introduce delays or intermittent resolution even when IPv4 works correctly.
Common glue-record failures
Glue is missing
The parent delegates to an in-bailiwick hostname but does not include its address. A resolver may be unable to escape the circular dependency, causing timeouts or SERVFAIL responses.
The address is stale
The authoritative server moved, but only the A or AAAA record in the child zone was changed. The parent continues directing resolvers to the old server through cached or live glue.
Parent and child NS sets disagree
The registry delegation lists servers that differ from the NS records served by the child zone. This does not always cause immediate failure, but it creates inconsistent authority and complicates caching and troubleshooting.
The server is reachable but not authoritative
Correct glue only provides an address. If the server at that address does not load the child zone or refuses public queries, the delegation is lame. Test that every listed server answers authoritatively for the domain.
Only one server or network works
Multiple NS names do not provide real redundancy when they resolve to one machine, one network path, or one unavailable location. Glue should describe an authoritative design that is actually reachable and resilient.
How to check DNS glue records
Start with a trace from the root toward the domain:
dig +trace example.com NS
At the parent referral, look for the delegated NS names and the associated A or AAAA records in the additional section. You can also query a parent server directly after identifying it:
dig example.com NS @a.gtld-servers.net
dig ns1.example.com A @a.gtld-servers.net
dig ns1.example.com AAAA @a.gtld-servers.net
The exact parent server depends on the top-level domain. Then query every delegated server directly:
dig example.com SOA @ns1.example.com
dig example.com NS @ns1.example.com
dig +tcp example.com SOA @ns1.example.com
Confirm that each server is reachable over UDP and TCP, returns an authoritative answer, serves the expected SOA serial, and publishes a child-side NS set consistent with the parent delegation.
Safely changing a glued name-server address
- Prepare the new server. Load the complete zone and verify authoritative answers before changing delegation data.
- Keep the old address active. Parent and resolver caches may retain the old glue until its TTL expires.
- Update the child host object. Use the registrar or registry workflow to change the parent-side glue.
- Update the child-zone address record. Make the A or AAAA record for the name server consistent with the new address.
- Query the parent and child separately. Do not rely on a single recursive resolver or control-panel display.
- Monitor during the cache window. Check availability, authoritative responses, and error rates from multiple networks.
- Retire the old server only after verification. Allow enough time for cached referrals to expire.
If the servers use primary-to-secondary replication, also verify that zone synchronization continues after the address change. The article DNS Zone Transfers Explained covers AXFR, IXFR, and secure peer configuration.
Glue records and DNS security
Glue is necessary routing information, but it is not a substitute for DNSSEC, secure registrar access, monitoring, or server hardening. Protect the registrar account because unauthorized changes to host objects or delegation can redirect resolution. Use multi-factor authentication and change controls where available.
The parent-child delegation model and the reason address records may be required in referrals are described in RFC 1034, Section 4.2.1.
Conclusion
DNS glue records solve a specific circular dependency: they give resolvers the address of an in-bailiwick authoritative name server before the child zone can be reached. Reliable operation depends on consistent parent glue and child-zone address records, reachable authoritative servers, correct NS sets, and careful migration timing. A trace and direct queries to both parent and child servers are the fastest way to verify the complete delegation path.
