Most people never touch a glue record, and that is fine, because most people use their registrar's or DNS host's nameservers. But the moment you run your own nameservers on your own domain, you hit a chicken-and-egg problem that glue records exist to solve. If you have ever set up custom nameservers and watched the domain simply refuse to resolve, a missing glue record is very often the reason.
The chicken-and-egg problem
Say your domain is example.com and you decide to run your own nameservers at ns1.example.com and ns2.example.com. Now a resolver trying to find your website asks the .com servers, "who is authoritative for example.com?" The answer is "ns1.example.com and ns2.example.com." So the resolver asks, "fine, what is the IP of ns1.example.com?" And the only place that answer lives is... inside example.com's own DNS, which it cannot reach yet because it does not know the nameserver's IP. It is stuck in a loop.
A glue record breaks the loop. It is an A (or AAAA) record for your nameserver, stored one level up at the parent (the .com registry), handed out alongside the delegation. So the resolver gets "example.com uses ns1.example.com, and by the way ns1.example.com is at 203.0.113.10" in the same breath. The glue is the IP address glued to the nameserver name at the parent zone.
When you need a glue record, and when you do not
- You need glue when your nameservers are subdomains of the domain they serve (ns1.example.com serving example.com). This is called an in-bailiwick nameserver, and without glue it cannot bootstrap. This is the classic case.
- You do not need glue when you use your DNS host's or registrar's nameservers (like ns1.somebighost.com). Those live under a different domain that resolves on its own, so there is no loop. This covers almost everyone. If you are just changing nameservers to a provider, see how to change nameservers safely.
How to tell a missing glue record is the problem
The symptom is a domain that will not resolve at all right after you set custom, in-domain nameservers, even though the nameservers themselves are running.
- Trace the delegation from the root. A delegation trace shows what the parent hands back for your nameservers. If it lists your nameserver names but no IP addresses (no glue), resolvers cannot proceed. Run a delegation trace.
- Check the registrar's nameserver registration. Glue is created by registering the nameserver as a host object (sometimes called a "host record," "private nameserver," or "register a nameserver") at your registrar, then assigning its IP. Setting the nameserver on the domain is not enough; the host object with its IP is what becomes glue.
- Confirm the nameserver actually answers at that IP. Glue only helps if the IP is right and the server responds. Verify reachability with an is-my-server-down check.
The fix, in order
- At your registrar, register each in-domain nameserver as a host object and give it the correct public IP. This creates the glue at the parent.
- Set the domain to use those nameservers.
- Wait for the parent zone to publish, then re-run a delegation trace and confirm the nameserver names now come back with IP addresses attached.
- Confirm the full path with a complete DNS test.
The one thing to remember
Glue records only matter when your nameservers live inside the very domain they are responsible for. In that case the parent zone must publish the nameserver's IP as glue, or nothing can find it. If you use a provider's nameservers, you never have to think about glue at all. Either way, a delegation trace tells you in seconds whether the glue is there.