Diagnose Broken DNS Glue Records Using Dig
Published:
04 Oct, 2026
Understanding In-Bailiwick Nameservers and Glue Records
A glue record is an A or AAAA record provided by a parent zone (such as a Top-Level Domain registry like .com or .org) that supplies the IP address of an authoritative nameserver located inside the domain it serves. These are known as in-bailiwick nameservers.
For example, if the domain example.com delegates its DNS to ns1.example.com, a recursive resolver cannot resolve example.com without querying ns1.example.com, but it cannot resolve the IP address of ns1.example.com without already having access to example.com. This circular dependency is broken by storing glue records directly in the parent TLD zone alongside the delegation NS records.
When glue records become out-of-sync, point to decommissioned IP addresses, or are omitted after a server IP migration, recursive resolvers experience cyclic resolution loops, elevated latency, or outright SERVFAIL failures.
Symptoms of Glue Record Failures
- Resolvers succeed when their cache is warm but fail randomly when querying authoritatively from a cold state.
- Some geographic regions resolve the domain normally while others return NXDOMAIN or SERVFAIL due to intermediate resolver caching differences.
- DNSSEC validation failures occur when parent DS records point to a zone that resolvers cannot reach via the parent glue.
- Nameserver IP migrations appear complete in the local zone files, but traffic continues hitting the old server IPs.
Step 1: Inspect Delegation and Additional Records with dig
To inspect what the parent registry actually hands out to recursive resolvers, query the parent TLD servers directly without recursion (using the +norecurse flag).
First, identify the authoritative nameservers for the parent TLD:
dig com. NS +short
Query one of the TLD authoritative nameservers directly for your domain delegation:
dig @a.gtld-servers.net example.com NS +norecurse
Analyzing the Response Sections
A healthy delegation response with in-bailiwick nameservers must include an AUTHORITY SECTION containing the NS records and an ADDITIONAL SECTION containing the glue records:
;; AUTHORITY SECTION:
example.com. 172800 IN NS ns1.example.com.
example.com. 172800 IN NS ns2.example.com.
;; ADDITIONAL SECTION:
ns1.example.com. 172800 IN A 198.51.100.10
ns1.example.com. 172800 IN AAAA 2001:db8::10
ns2.example.com. 172800 IN A 198.51.100.20
ns2.example.com. 172800 IN AAAA 2001:db8::20
If the ADDITIONAL SECTION is empty, or if it lists IP addresses that no longer respond to DNS queries on UDP/TCP port 53, your domain suffers from a glue record failure.
Step 2: Detecting Mismatches Between Parent and Child Zones
A frequent operational error occurs when an administrator updates the A/AAAA records inside their own authoritative zone file (the child zone) but forgets to update the host records at the domain registrar (the parent registry).
Query the child authoritative nameserver directly for its own host records:
dig @198.51.100.10 ns1.example.com A +norecurse
| Source | Query Target | Expected Value | Diagnostic Implication |
|---|---|---|---|
Parent TLD (e.g., a.gtld-servers.net) |
dig @parent example.com NS (Additional Section) |
198.51.100.10 |
Outdated IP here causes resolver bootstrap timeouts. |
Child Zone (e.g., ns1.example.com) |
dig @child ns1.example.com A (Answer Section) |
198.51.100.10 |
Discrepancy between parent and child leads to split-brain routing. |
Step 3: Tracing Resolution Path Step-by-Step
To view how a full resolver traverses the delegation chain from root to child, execute a trace:
dig example.com +trace +nodnssec
Inspect the output at the transition point between the root (.), the TLD (.com), and your authoritative nameservers. Look for warnings such as:
;; couldn't get address for 'ns1.example.com': not found
;; received unreachable response from 203.0.113.5#53(ns1.example.com)
Resolving Glue Record Inconsistencies
- Log into your Domain Registrar portal: Navigate to the section labeled Registered Nameservers, Host Records, Child Nameservers, or Glue Records (terminology varies by registrar).
- Update the IP mappings: Ensure the IPv4 and IPv6 addresses match the exact records configured in your BIND, NSD, PowerDNS, or Knot zone files.
- Remove orphan glue: If you decommissioned an old nameserver (e.g.,
ns3.example.com), delete the host registration at the registrar in addition to removing the NS record in the child zone. - Verify IPv6 reachability: If AAAA glue is published, ensure the nameserver daemon is actively listening on IPv6 (
netstat -lnptu | grep namedorss -ulpn 'sport = :53'). A non-responsive IPv6 glue address causes resolver fallback delays.
Independent Verification Workflow
Because local recursive resolvers cache parent TLD responses according to the TLD TTL (often 48 hours / 172,800 seconds), testing exclusively from your local workstation can mask propagation status.
Verify that external public resolvers and registry endpoints reflect your changes by using the InfoWebStats DNS Lookup tool to query authoritative nameservers from independent nodes, or inspect registrar registration status via the InfoWebStats Whois / RDAP Lookup tool to confirm host object synchronization across registry databases.