DNS Info Zone DNS,DNS records DNS Glue Records Explained: How They Prevent Delegation Loops

DNS Glue Records Explained: How They Prevent Delegation Loops

September 29, 2026September 29, 2026| DanielDaniel| 0 Comment | 5:10 am
DNS glue records
Categories:

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

  1. Prepare the new server. Load the complete zone and verify authoritative answers before changing delegation data.
  2. Keep the old address active. Parent and resolver caches may retain the old glue until its TTL expires.
  3. Update the child host object. Use the registrar or registry workflow to change the parent-side glue.
  4. Update the child-zone address record. Make the A or AAAA record for the name server consistent with the new address.
  5. Query the parent and child separately. Do not rely on a single recursive resolver or control-panel display.
  6. Monitor during the cache window. Check availability, authoritative responses, and error rates from multiple networks.
  7. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Post

Traceroute command

Traceroute command explainedTraceroute command explained

If you want to know everything about the traceroute command, you came to the right place. Here you will learn what is it, why to use it and how.

Traceroute command explained

Traceroute command, just like the rest of the popular network commands, is a simple small software with command-line interface (CLI) and comes built-in on most Linux distros, BSD distros and even macOS.

It is easy to understand its purpose, to trace the route of a query, from your computer, through all the routers (hops) on the way, to the target that you set.

The result will be data on each hop (host name and IP address), showing if the packets of data arrive and after what amount of time, and which was the next hop.

Traceroute options for Windows, Linux, and macOS

(more…)

Read MoreRead More
DNS TTL

DNS TTL Explained: How to Choose the Right Cache TimeDNS TTL Explained: How to Choose the Right Cache Time

Every DNS record includes a setting that influences how long other systems remember its answer. That setting is the Time to Live, or TTL. It is measured in seconds and tells recursive resolvers how long they may keep a cached DNS response before asking an authoritative DNS server for fresh data.

TTL affects much more than perceived “DNS propagation.” It shapes query volume, response speed, change management, failover behavior, and the load placed on authoritative infrastructure. The best value is therefore a balance: long enough to benefit from caching, but short enough to support the domain’s operational needs.

What happens during the DNS TTL lifecycle?

When a recursive resolver receives a record from an authoritative server, it stores the result together with its TTL. The remaining lifetime counts down while the answer sits in cache. If another user asks for the same record before the timer expires, the resolver can answer from cache without repeating the full lookup.

After the cached value expires, the resolver must obtain an updated answer. This normal caching process is part of the broader resolution flow described in Domain Name System (DNS) explained.

TTL does not instruct every resolver to update at the same instant, and it does not push a new record across the Internet. Different caches learn about a record at different times, so they also expire at different times. Some clients may already have the new answer while others still legitimately use the previous cached value.

Why a longer TTL can be useful

A longer TTL allows recursive resolvers to reuse answers for more time. This provides several practical advantages:

  • Fewer authoritative queries. More requests are answered from recursive caches, reducing traffic to authoritative DNS servers.
  • Efficient lookups. A cached response avoids repeating the full resolution path and is usually returned quickly.
  • Resilience during brief problems. Previously cached records may remain available to users while an authoritative server experiences a short interruption, provided the cached TTL has not expired.
  • Predictable operation for stable records. Records that rarely change do not need to be refreshed every few minutes.

The tradeoff is slower adoption of planned changes. If an A or AAAA record has several hours remaining in cache when its authoritative value changes, clients behind that resolver may continue using the old address until the timer reaches zero.

Why a shorter TTL is not always better

A short TTL can make changes visible sooner after cached answers expire, which is useful during a migration or for some automated failover designs. It also causes resolvers to query authoritative servers more frequently. At scale, that can increase DNS traffic and make the quality and geographic reach of the authoritative service more important.

Short values do not guarantee instant switching. Applications, operating systems, local forwarders, browsers, and recursive resolvers can each participate in caching. A low TTL also cannot help clients that already received a longer value before it was reduced. Operational planning matters as much as the final number.

Practical TTL ranges for common situations

There is no universal value that fits every record and every domain. The following ranges are useful starting points, not strict rules:

  • Stable website records: 3,600 to 14,400 seconds can provide a reasonable balance when the destination changes infrequently.
  • Planned migration: 300 to 900 seconds can reduce the cache window during the change. Lower the TTL early enough for the previous, longer value to expire before migration begins.
  • DNS-based failover: 60 to 300 seconds may support faster refreshes, but only when monitoring, authoritative capacity, and recovery procedures are designed for the higher query rate.
  • Stable infrastructure records: Values from several hours to a day may be appropriate when the records are carefully managed and rarely changed.

For example, changing a TTL from 86,400 seconds to 300 seconds five minutes before a migration is too late for resolvers that already cached the one-day value. Reduce it at least one full old-TTL period before the planned change. After the migration is confirmed, restore an efficient steady-state value rather than leaving an unnecessarily short TTL forever.

TTL planning for failover and monitoring

TTL is only one part of a failover design. A system must detect the problem, decide whether a change is safe, update the authoritative record, and allow cached answers to expire. A very short TTL cannot compensate for slow detection or an unreliable update process.

This is why DNS monitoring should test both availability and correctness from multiple locations. Teams should also measure authoritative query volume before adopting very short values.

Redundant authoritative infrastructure addresses another part of the problem. A secondary server can continue answering for a zone if the primary becomes unavailable. The architecture and terminology are covered in Get familiar with Secondary DNS. Record TTLs and secondary DNS serve different purposes, but both belong in a complete resilience plan.

Common DNS TTL mistakes

Reducing the TTL too late

The previous TTL remains relevant until every cache holding that response has had time to expire. Schedule the reduction before the maintenance window, not at the moment of the record change.

Using one value for every record

Records have different change patterns and risks. A frequently updated service endpoint may need a shorter value than stable nameserver or verification records. Choose TTLs according to how each record is operated.

Leaving emergency values in place

Teams often reduce TTLs for a migration and forget to raise them afterward. This creates continuous extra query traffic without an ongoing operational benefit.

Treating TTL as a security control

TTL controls cache duration; it does not authenticate an answer or encrypt a query. DNSSEC, protected account access, change auditing, resilient authoritative service, and encrypted transports address separate security concerns.

A simple decision process

  1. Identify how frequently the record changes during normal operation.
  2. Define how quickly users must receive a new answer during a planned change or failure.
  3. Estimate whether the authoritative service can handle the resulting query rate.
  4. Lower the TTL in advance of maintenance and wait for the old cache window to pass.
  5. Monitor the change from multiple networks and restore the steady-state TTL afterward.

For a broader operational checklist, see DNS best practices. The original DNS protocol specification defines the TTL field and caching behavior in RFC 1035: Domain Names—Implementation and Specification.

Conclusion

A well-chosen DNS TTL supports both efficiency and controlled change. Longer values reduce repeated authoritative lookups, while shorter values narrow the cache window when records must change quickly. The right approach is to use stable defaults, lower values deliberately before planned work, monitor the results, and return to an efficient setting when the event is complete.

Read MoreRead More