Glue records are one of those DNS details you only notice when they break. They sit at the boundary between the parent zone (like .com) and your domain, and they can determine whether resolvers can even reach your authoritative nameservers. In this article we explain what glue records are, when they are required, how they improve reliability, and how to check your own domain for glue with simple, practical commands.
What glue records are (and the DNS “chicken and egg” problem)
DNS resolution is a chain of referrals. A recursive resolver asks the root, then the TLD (like .com), then your domain’s authoritative nameservers. At the delegation point, the parent zone answers with NS records that name the authoritative servers for your domain. The key detail is that an NS record contains only a hostname (for example, ns1.example.com), not an IP address.
This design is flexible, but it creates a fundamental circular dependency when your nameservers live inside the domain they serve:
- You register example.com and set its nameservers to ns1.example.com and ns2.example.com.
- A resolver asks a .com nameserver: “Who is authoritative for example.com?”
- .com replies: “ns1.example.com, ns2.example.com.”
- The resolver now needs the IP for ns1.example.com to continue.
- But to get the IP for ns1.example.com, it would normally ask the authoritative zone for example.com.
- The authoritative zone for example.com is… ns1.example.com.
That’s the “chicken and egg” problem. Glue records solve it by letting the parent zone include “bootstrap” IP addresses for in-domain nameservers in the Additional section of the referral response. In practice, glue is the A/AAAA record data that the TLD publishes alongside the NS delegation so resolvers can contact your nameserver without first resolving its name through your zone.
There is also an important trust boundary concept called bailiwick. Resolvers only trust additional data that is relevant to the delegation and within the parent’s administrative scope. That’s why glue is primarily associated with in-bailiwick nameservers (nameservers that are subdomains of the delegated domain). For out-of-bailiwick nameservers (like ns1.dnsprovider.net for example.com), the .com registry typically does not (and should not) provide glue, because it is not authoritative for that host and it could be abused for cache poisoning.
Why glue records matter for reliability (and where outages come from)
Glue is mandatory for in-domain nameservers, but it also affects real-world reliability in ways many teams do not model until an incident happens.
1) Preventing “self-hosted DNS” dead ends
If you run vanity nameservers such as ns1.domain.com, ns2.domain.com for domain.com, glue is what makes the delegation resolvable at all. Without it, resolvers cannot reach your authoritative servers, and the domain effectively disappears for users who do not already have cached addresses.
2) Reducing dependency on other zones – avoid unnecessary outages of your domain.com
Your example is a common and painful failure mode: domain.com delegates to nameservers like ns1.dnsprovider.org. In that setup, resolving domain.com depends on more than just .com and your DNS provider. It also depends on the availability and correctness of the .org registry (and potentially the provider’s own DNS chain). If the .org registry has an incident where dnsprovider.org (or a critical nameserver hostname under it) becomes hard to resolve, recursive resolvers can fail to discover the IP addresses of your authoritative nameservers. Even though domain.com itself is under .com, the delegation becomes unreachable because the resolver cannot “find” your nameserver IPs.
Glue records can eliminate that class of dependency only when the nameserver hostnames are within your own domain (in-bailiwick). In other words, if you operate ns1.domain.com and publish correct glue at .com, resolvers can reach your authoritative servers using only the .com referral response, even if other TLDs are having a bad day.
3) Faster cold-cache resolution and fewer moving parts
Glue also improves performance characteristics of the delegation path. When a resolver receives NS plus glue A/AAAA in the same referral, it can immediately contact the authoritative server. Without glue (or without cached addresses), it must perform extra lookups to find nameserver IPs first. Those extra lookups add latency, increase the number of network round trips, and create more failure points (timeouts, packet loss, rate limits).
4) Operational risks: stale glue and long TLD TTLs
Glue records are easy to set and forget, which is exactly why they become risky:
- Stale glue: if you move authoritative DNS to new IPs but forget to update the glue at the registrar/registry, many resolvers will keep trying the old IPs until caches expire. In the worst case, if those old IPs are later reassigned, stale glue can become a security problem.
- Slow propagation: TLD glue TTLs are commonly long (often around 48 hours). Even if you lower TTLs inside your zone, you cannot force the internet to forget old glue quickly. Plan nameserver IP migrations accordingly.
- DNSSEC nuance: glue is a hint in the referral response, and it is not the same as authoritative address records served by your zone. Validating resolvers ultimately rely on DNSSEC in the child zone for authoritative data, but glue still influences the path taken to reach your servers.
How to check if your domain example.com has glue records
The most reliable way to inspect glue is to query the parent (the TLD nameservers), because glue is published there. If you ask your own authoritative nameservers or a public resolver (like 8.8.8.8), you are not directly verifying what the registry is returning at delegation time.
Step 1: Find the TLD nameservers
For a .com domain, first list the .com authoritative servers:
dig com NS +short
Step 2: Ask a TLD server for your domain’s NS delegation
Pick one TLD server from the list (example: a.gtld-servers.net) and query it directly:
dig @a.gtld-servers.net example.com NS
Step 3: Read the response correctly
- Look at the AUTHORITY SECTION for the NS names (this is the delegation).
- Then check the ADDITIONAL SECTION for A/AAAA records corresponding to those NS names. Those A/AAAA records are the glue.
What “glue present” typically looks like
Scenario: example.com uses ns1.example.com and ns2.example.com.
- AUTHORITY SECTION contains NS records for ns1.example.com and ns2.example.com
- ADDITIONAL SECTION contains A and/or AAAA records for ns1.example.com and ns2.example.com
This indicates the parent zone is providing glue, which is required for in-domain nameservers.
What “no glue” can mean (and when it is normal)
Scenario: example.com uses ns1.provider.net and ns2.provider.net.
- AUTHORITY SECTION contains NS records pointing to ns1.provider.net and ns2.provider.net
- ADDITIONAL SECTION may be empty or not include A/AAAA for those nameservers
This is usually normal, because those nameservers are out-of-bailiwick for .com. The resolver is expected to resolve ns1.provider.net via .net separately.
Quick “follow the delegation” check with +trace
If you want to see the whole chain in one run:
dig example.com NS +trace
Scroll to the point where the .com servers refer you to example.com’s nameservers. If you see IP addresses alongside the in-domain NS hosts in that hand-off, that is glue being provided by the TLD.
Self-test exercise for readers (use your own domain)
- Run dig yourtld NS +short (replace .yourtld with .com, .net, .org, etc.)
- Query one TLD server directly: dig @tld-server yourdomain.tld NS
- Write down the NS names from the Authority section
- Check whether the Additional section contains A/AAAA for those exact NS names
- If your NS names are inside your domain and there is no glue, treat it as a critical issue to fix at your registrar (often called “registering host objects”, “private nameservers”, or “child nameservers”)
Conclusion
Glue records are the small DNS mechanism that prevents big failures: they break circular dependencies for in-domain nameservers and make delegations more resilient and faster by reducing extra lookups. They also introduce operational responsibilities, especially keeping glue IPs synchronized and planning around long TLD TTLs. If you run vanity nameservers or care about outage-proof DNS, regularly verify glue at the registry with direct TLD queries.