DNS Glue Records resolve the chicken-and-egg problem in nested delegations by providing IP addresses for name servers located within their own zone. I'll show you how delegation, how parent zones, NS records, and A/AAAA glue records work together, and why this additional data is what makes resolution possible in the first place.
Key points
To help you get your bearings quickly, I’ll briefly summarize the main points and highlight the key elements.
- Glue resolves circular dependencies in delegations.
- Parent zone provides NS and IP records for in-domain name servers.
- NS specifies responsibility, A/AAAA makes it accessible.
- Actuality The Glue data prevents outages after an IP change.
- Documentation ensures that chains of command and responsibilities are transparent.
Why Glue Records Are Necessary
In my projects, I often come across delegations where the authoritative nameserver is located in the same zone it is supposed to serve, and this is exactly where Glue. Without the IP information from the parent zone, the resolver would know the hostname of the relevant server but not its address. The lookup would get stuck because the child zone would only be accessible once the resolver knows the address, which would result in a The chicken or the egg-loop. Glue Records resolves this loop by including the IP addresses for the in-domain nameservers along with the delegation. This allows the resolver to reach the authoritative server directly and then retrieve the actual zone data as usual.
Clearly separate the delegation, parent, and child zones
When planning, I make a clear distinction between responsibility and availability so that the delegation works. The parent zone specifies the authoritative servers via an NS record; this indicates which servers are authorized to respond. However, if these server names are located within the delegated zone, the parent zone must also provide their A or AAAA addresses. For a quick overview of the roles and settings of a nameserver, see „What is a nameserver?“, which helps with resolution. Only the combination of the NS reference and the glue records ensures that the resolver can contact the appropriate server.
Practical example: ns1.example.com as the authoritative server
Let's take the example.de zone, whose authoritative servers are named ns1.example.de and ns2.example.de, and consider the Glue-Requirement. These hostnames are located in the zone to be delegated, so NS records in the parent zone are not sufficient. The registry or registrar also requires the IPv4 and/or IPv6 addresses of these hosts—that is, A and AAAA records—which are stored as glue data. The resolver therefore receives not only the NS names in the delegation response, but also the IPs for direct contact. Only then can the first query to the child zone succeed, which is subsequently resolved authoritatively with the actual Zone data replies.
Technical Details: Additional Section and Response Paths
When I run tests, I pay attention to where the Glue-information appears in DNS responses. Glue records typically appear in the Additional Section alongside the Referral record because the parent zone is not permitted to provide authoritative responses for child zone content. The parent server thus provides only auxiliary data to enable the resolver to direct its own queries to the correct locations. RFC 9471 [7] requires that authoritative servers return all available glue records for in-domain nameservers in referral responses to maintain reliable resolution. It is precisely this separation that protects the Authority the child zone and prevents data inconsistencies.
Maintenance and modifications without downtime
I never plan IP changes for nameservers on the fly, because outdated Glue-Otherwise, this could lead to outages. If the address of an in-domain nameserver changes, the update must be made both in the zone and with the registry or registrar. Only once the parent has accepted the new A/AAAA records is the path clear for resolvers again. During the transition, I recommend using TTL values so that caches can quickly process the change. Anyone who skips these steps risks Incorrect solutions even though the zone file is correct.
Common Problems and Solutions
I keep coming across recurring patterns that, when viewed in light of Glue quickly identify and resolve. A common issue is missing A/AAAA records at the registrar, even though the NS records in the zone are functioning properly. Equally common are typos in hostnames or unexpected firewall restrictions that prevent the site from being reached. A TTL that is too long in the parent cache also noticeably delays new addresses. The following table summarizes common symptoms, causes, and remedies so that you can quickly identify and resolve issues. prioritize.
| Problem | Symptom | Probable cause | Measure |
|---|---|---|---|
| Glue is missing | Delegation cuts short its visit | No A/AAAA record at the registrar | Store IP addresses as glue |
| Old IP in the parent | Partial unavailability | Forgot to update with the registrar | Update the registrar entry, wait for the caches to refresh |
| Incorrect hostname | NXDOMAIN at NS-Host | Typos in NS or Glue | Standardize names, retest delegation |
| Firewall is blocking | Timeout despite correct glue | Port 53 (UDP/TCP) is filtered | Share rules, check coverage |
| TTL too high | Long transition periods | The cache retains old data | Lower the TTL before making changes, then raise it again afterward |
After each correction, I first verify reachability via DNS against the parent zone and then against the authoritative servers in order to Consistency to see. I then check the caches of several public resolvers to make sure I’m not misled by local effects. This order prevents misinterpretations and keeps downtime to a minimum. In addition to A/AAAA, test AAAA on its own if IPv6 is running independently. This way, you’ll discover Asymmetries, that would otherwise be overlooked.
Understanding Power, Resolvers, and TTL
I observe how resolvers cache Glue data, thereby speeding up the initial connection, which Latency . Smart use of TTL for NS and Glue servers avoids unnecessary round trips without blocking the failover path. Before making major changes, I lower the TTL in advance so that new IPs propagate quickly. After a successful transition, I raise the TTL again to keep lookups efficient. Anyone who wants to learn more about caches, recursors, and timeouts can find information at „DNS Architecture and Caching“a concise summary that this Mechanisms tangible.
When Glue is not required: out-of-bailiwick nameservers
I avoid Glue when I'm intentionally configuring the nameservers outside in the zone to be delegated. If, for example, the NS records for example.com point to ns1.provider.net, the hostname is out-of-bailiwick. In this case, the parent zone must not and should not provide any glue records; the resolver queries the A/AAAA records of the nameserver normally from the relevant domain of provider.net. This reduces maintenance effort for the registrar and avoids duplicates. I like to use this strategy for many zones on the same authoritative cluster because it allows me to centrally manage IP changes without having to modify glue records for each child zone.
Bailiwick Rules, Security, and „Lame Delegations“
When evaluating Glue, I follow the Bailiwick rules, which require resolvers to Glue poisoning protect. Only additional data that falls within the jurisdiction of the responding server is accepted. Modern resolvers typically ignore out-of-bailiwick information in the Additional section. This reduces the attack surface where false IP addresses could be substituted for nameservers. At the same time, I check for „lame delegations“: This occurs when the parent zone points to name servers that are not authoritative for the child zone. Lame delegations lengthen resolution paths, increase timeouts, and are a reliable warning sign of configuration drift. I detect them by running direct NS queries against the supposedly authoritative servers and fix them immediately.
Naming and architectural decisions: with or without glue
I make a conscious decision as to whether nameservers should be located within the zone (e.g., ns1.example.de) or in a neutral infrastructure (e.g., ns1.example-dns.net). The Advantage of in-domain: Consistent branding, easy identification during monitoring and audits. The Advantage of out-of-domain: No glue server maintenance, fewer registry workflows, and often faster renumbering. For large setups, I combine both: at least one nameserver outside the network (to avoid a single point of failure with glue records) and one inside (for visibility and independence). This hybrid approach provides robustness during migrations and minimizes lock-in risks.
Registrar Workflows and Host Objects
In practice, I've noticed two patterns: Some registries maintain Host objects or „child hosts,“ which store the name server’s hostname along with its IP addresses. Changes to IP addresses must be requested separately there. Other registrars hide this behind interfaces where the glue records are managed for each domain. For Bulk changes I rely on API-based updates because this allows me to plan renumbering in a reproducible, time-coordinated manner with rollback capabilities. The order is important: create new IPs, test reachability, lower the TTL, change the delegation, remove old IPs. I avoid deleting host objects as long as any zone still points to them, in order to abandoned to prevent delegations.
IPv4/IPv6, EDNS, and response sizes
I consistently apply glue dual stack (A and AAAA), provided the nameserver supports both protocols. This reduces the need for routes through gateways or NAT64/NAT46 and makes connectivity more robust. At the same time, I keep an eye on packet size: referral responses with many NS records plus associated glue records can become large via EDNS. Truncation leads to a TCP fallback; this is correct, but can be slow if firewalls do not properly allow TCP/53. That’s why I aim for a lean NS list (typically two to four servers) and test whether both UDP with EDNS and TCP work reliably. I also verify that the MTU on the network doesn’t cause fragmentation issues with large DNS responses.
Split horizon and internal zones
I make a strict distinction between internal and external DNS views. If the nameserver hostnames are in the public zone, their A/AAAA records must also publicly must be reachable—otherwise, glue records will point to nowhere. For pure intranet zones with private addresses, I do not set up public delegation and therefore do not use public glue records. Where split horizon is necessary (e.g., different responses internally/externally), I verify that the external glue addresses point to public interfaces accessible from the Internet and that firewall rules reflect this. This prevents resolvers from „pointing“ externally to internal networks.
DNSSEC: Order of Key and Delegation Changes
I plan DNSSEC rollouts and transitions in sync with delegation: First, I ensure that the authoritative servers are reliably accessible (glue records up to date, delegation consistent), then I maintain DS records on the parent zone and check RRSIGs in the child zone. During key rotations, I ensure that validators always see a valid path during the transition phase; glue records remain unsigned, but without proper reachability, validators cannot retrieve signed responses. Therefore, the stability of the delegation chain Priority, signature details follow immediately after.
Monitoring, Testing, and Automation
I use recurring tests to detect glue bugs early on:
- Check referral:
dig +norecurse NS example.com @a.nic.de(on behalf of Parent). In the Additional Section, I'm looking for A/AAAA records for in-domain NS. - Run the trace:
dig +trace example.com NSshows the entire chain from root to child. - Directly against authority figures:
dig @ns1.example.com SOA example.comanddig -6 @ns1.example.com SOA example.comfor IPv6. - TCP fallback:
dig +tcp NS example.com @a.nic.com, to cover truncation scenarios.
For many zones, I create checks that compare delegation data (parent) with zone files (child) and report any discrepancies. Even a minor difference in spelling, TTL, or IP address is enough to cause sporadic errors during peak traffic periods. Automated workflows lower the TTL before making changes, enter glue records, check reachability, then raise the TTL again and log the changes. This ensures that deployments remain traceable and reproducible.
Migration Patterns and Fallback Strategies
I prefer to move in stages to avoid downtime:
- Preparation: Provision new nameserver IP addresses, create a glue record with the registrar, enable monitoring, and reduce the TTL in the child zone and—if possible—in the parent zone.
- Parallel operation: Run both old and new IP addresses simultaneously for a while. This gives resolvers a chance to update their caches.
- Switch window: Update delegation, monitor logs for NXDOMAIN/timeouts, test TCP fallback.
- Adjustment: Do not remove old Glue addresses until no further access is detected and the TTL windows have definitely expired.
If major renumbering is coming up, I plan to create temporary additional NS records, to distribute the load and reduce the risk to individual hosts. Anyone using Anycast should ensure that all edge servers are serving the new prefixes and that health checks are functioning properly before the delegation change—otherwise, inconsistent behavior may occur depending on the location.
Operational Reliability: Firewalls, Rate Limits, and Capacity
I regularly check whether UDP/53 and TCP/53 are reachable, even from networks with strict egress rules. Rate limits (e.g., RRL) on authoritative servers must not slow down legitimate burst scenarios when many resolvers simultaneously fetch fresh data following a change. Capacity bottlenecks often manifest as sporadic timeouts and are mistakenly attributed to Glue. I therefore correlate latencies, packet loss, and server utilization—only once the transport layer is clear is it worth looking into the delegation details.
Typical questions to consider before going live
Before every delegation, I ask myself four short questions:
- Are there one or more NS hostnames in the child zone? If so, I need Glue in the parent.
- Have I checked for dual-stack connectivity, and are A/AAAA records configured in the parent zone?
- Is the NS list lean, distributed globally, and does every host actually respond authoritatively?
- Have the TTLs been set and documented appropriately for a potential quick change?
If I can answer „yes“ to all the questions, the risk of surprises during operation is significantly reduced. If any question remains unanswered, I’ll postpone the go-live in favor of a short, scheduled window for final adjustments—this saves a lot of troubleshooting under pressure later on.
Documentation and Handover as a Team
For each zone, I document the authoritative servers, the NS records in the parent zone, and the stored Glue-addresses and the contact person at the registrar. I also note down TTL values, maintenance windows, and contacts for making quick changes. This overview reduces risks associated with staff changes, audits, or incident response. Those who manage many subdomains benefit from a consistent scheme for hostnames and addressing. This ensures that the Traceability high and the error rate low.
Briefly summarized
Let me summarize the main points: DNS Glue Records These are the address entries required for delegation, without which in-domain nameservers would be unreachable. They belong in the parent zone, appear in the Additional Section, and resolve the startup issue associated with nested delegations. Keeping them up to date prevents outages during IP changes and minimizes disruptions. Combined with smart TTLs, clear documentation, and DNSSEC, this creates a resilient resolution chain. With this perspective on delegation By planning for scalability and availability, you can ensure that your domains will function reliably as your business grows and undergoes changes.
