The countdown to Elevate 2026 is on. Join us in Chicago, London, or Sydney.

Register here

Partners

Docs

LM Academy

LM Community

Pricing

Platform
Solution
Industry
Role
There is no result.
Try it free

14-day access to the full LogicMonitor platform

The countdown to Elevate 2026 is on. Join us in Chicago, London, or Sydney.

Register here

LOGICMONITOR BLOG

Stale DNS Glue Records: How to Diagnose Parent-Authoritative Mismatches

Your authoritative servers return the right IP, but users still hit the old one. Here’s how to find stale glue records and fix the parent-zone referral.

5–7 minutes
Denton Chikura

NEWSLETTER

Subscribe to our newsletter

Get the latest blogs, whitepapers, eGuides, and more straight into your inbox.

SHARE

The quick download:

When a parent zone keeps serving stale glue records, resolvers send users to dead IPs even after your authoritative servers are already correct.

  • The parent (delegation) and child (authoritative) can disagree, and resolvers follow the parent, so a healthy authoritative zone won’t save you.

  • Catchpoint traced this exact failure in 2017: a China-based CDN provider’s registrar left old glue in the parent zone, so users kept resolving to the outdated address.

  • You can isolate it by confirming the authoritative answer is correct, then querying the gTLD servers directly with dig to catch the stale referral.

  • Monitor the parent referral alongside the authoritative record so you catch a glue mismatch before customers do.

One of the most confusing DNS failures looks healthy from the inside. You query your authoritative nameservers, and they return the correct, current IP addresses. Yet resolvers keep sending users to old addresses, and traffic lands on infrastructure you already retired.

The authoritative answers are correct, and the problem sits one layer up, in the path resolvers take to reach them.

When the parent-zone referral carries stale glue, the delegation layer above your authoritative servers keeps handing out addresses your team fixed days ago, and the mismatch hides in plain sight until someone maps resolution across every layer.

Why stale glue still bites in 2026

Modern delivery leans on layers you don’t operate directly. Multi-CDN and multi-cloud setups, edge delivery, and API dependency chains all resolve through third-party DNS and registrars, so a single wrong address in the delegation layer can misroute real traffic.

When glue goes stale, the damage is uneven and hard to read: some regions resolve correctly while others fail, transactions drop for a subset of users, and API calls break for partners who happen to hit a resolver holding the wrong data. Partial availability like that is harder to triage than a clean outage, because the parts that work suggest the problem is somewhere else.

The one DNS distinction that matters here

Diagnosing stale glue comes down to one distinction. Delegation data lives in the parent zone and tells resolvers which nameservers are authoritative for your domain, along with their addresses. Authoritative records live in the child zone and hold the actual answers your nameservers return.

These are two separate sources, maintained through two separate channels, and they can disagree. When they do, resolvers follow the parent, not the child. For troubleshooting stale glue, the parent-versus-child split is the only piece you need.

If you want the full picture of how the hierarchy and delegation fit together, see our DNS delegation guide.

What a glue-record mismatch looks like

Glue records are A and AAAA address records that the parent zone supplies for your delegated nameservers, per RFC 9471. They show up in the Additional section of a referral, though the Additional section can carry other records too, so “additional records” isn’t a synonym for glue.

Glue is strictly required for in-domain nameservers, meaning nameservers whose hostnames sit inside the domain they serve, because resolving them any other way creates a circular dependency: you can’t reach the nameserver without its address, and you can’t get its address without reaching the nameserver.

A mismatch shows up as a disagreement between two sources:

  • The parent zone or TLD referral returns the old nameserver address in its glue.
  • The child authoritative answer returns the current, correct address.
  • The resolver trusts the parent referral, so it uses the stale address and never reaches the corrected records below.

Case study: valid answers, wrong addresses

This issue was originally investigated in 2017 by Catchpoint, a LogicMonitor company.

The customer was a leading CDN provider headquartered in China. They reached out after noticing that two of their nameservers were returning out-of-date A records. The symptoms were deceptive: the records looked valid, so nothing appeared obviously wrong, but they pointed to addresses the customer no longer used.

Because the answers parsed cleanly, the team’s first instinct was to trust the authoritative side, which is exactly where the investigation started.

How the mismatch was isolated

The investigation followed a clear evidence sequence, comparing what each layer returned:

  • The authoritative side was healthy: A test that queried the authoritative nameservers directly returned the correct, current IPs. That ruled out the child zone as the source of the problem.
  • The parent referral told a different story: A test that followed the parent-zone and TLD referral path, reading the delegation and its Additional section, returned the stale IPs.
  • A manual query confirmed it: Running dig, an external command-line utility rather than a LogicMonitor feature, against the relevant parent-zone authoritative server (in this case the gTLD servers, a-m.gtld-servers.net) returned the same stale answer. That confirmed the mismatch sat in the delegation layer.
  • The evidence went to the registrar: With the parent and child responses side by side, the customer had a concrete conflict to escalate, which pointed the fix at the right party.

The root cause was a stale glue record. The customer had submitted the address change through their registrar, but the updated glue was never published in the parent zone, so the delegation layer kept serving the old addresses while the authoritative servers served the new ones.

A practical diagnostic workflow

When resolution returns valid-looking answers that still send users to the wrong place, work through the layers in order:

  • 1. Confirm the user-facing symptom: Reproduce the bad resolution and note where and for whom it fails, since stale glue often affects only some regions or resolvers.
  • 2. Query the authoritative nameserver directly: If it returns the correct, current addresses, the child zone is healthy and the problem sits above it.
  • 3. Inspect the parent-zone delegation and glue: Read the referral from the parent zone or TLD server and check the addresses in its Additional section.
  • 4. Compare A and AAAA values between parent and child: Line up the parent’s glue against the authoritative answers. Any difference in the IPv4 or IPv6 records is your mismatch.
  • 5. Escalate to the registrar with the conflicting responses: Send the parent and child answers together so the registrant can resubmit the change and the registry can republish correct glue in the parent zone.

How to verify the fix

A registrar update isn’t done until the parent zone actually serves the new glue everywhere. Query every relevant parent-zone or TLD server, not just one, since they can update at different times.

Account for caching and TTLs, because resolvers may hold the old glue until it expires. Then confirm resolution from multiple geographic locations, so you know the corrected addresses are reaching users rather than a single vantage point you happened to test from.

Detecting the mismatch before users report it

Stale glue is easiest to catch when you compare resolution behavior across layers instead of trusting any single one.

LogicMonitor’s approach to DNS monitoring enables you to see how queries resolve from root and parent/TLD down to authoritative nameservers in different regions, turning parent–authoritative divergence and stale delegation into measurable issues rather than user-reported incidents.

LogicMonitor Synthetics and Internet Performance Monitoring provide the outside-in, multi-location view of the resolution path, the same kind of layered comparison the 2017 investigation ran by hand. When an external DNS issue overlaps with your own environment, LM Envision ties that Internet-facing signal back to internal infrastructure health, and Edwin AI helps separate real problems from noise.

Together, that shortens the time from symptom to root cause and helps you find a mismatch before it reaches users.

Catch stale glue mismatches before your users resolve to a dead IP.

LogicMonitor compares the parent referral and the authoritative answer, so a delegation drift shows up as an alert instead of a support flood. See how proactive DNS monitoring closes the gap.

FAQs

What are DNS glue records and why do they cause outages?

Glue records are the IP addresses for a domain’s nameservers, published in the parent (delegation) zone. Resolvers use them to reach your authoritative servers. When the parent keeps old glue after your nameserver IPs change, resolvers follow the stale address and users hit a server that no longer answers, even though your authoritative zone is correct.

How do I tell whether the problem is in the parent zone or my authoritative servers?

Query your authoritative nameservers directly and confirm they return the current IP. Then run dig against the gTLD servers to see the parent referral. If the authoritative answer is correct but the parent hands back an old address, the mismatch lives in the parent zone and points to a registrar or delegation issue.

After the registrar updates the glue, how do I verify the fix actually took?

Query every TLD server for the domain to confirm they all return the new glue, since a single server can lag. Account for caching and TTLs, because resolvers may serve the old value until it expires. Then check resolution from multiple regions to confirm users worldwide reach the correct address.

By Denton Chikura

Technical Writer

Denton Chikura is a technical writer and longtime observability advocate focused on helping site reliability engineers and engineering teams discover the tools and capabilities that strengthen internet resilience. He works at the intersection of monitoring, performance, and infrastructure to make complex systems more understandable and usable, bridging the gap between deep technical detail and real‑world operations. His goal is to help teams build faster, detect issues earlier, and recover smarter, ultimately making the internet a better, more reliable place for everyone.

Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

© LogicMonitor 2026 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Related Blogs

Observability ROI: Real Savings From Real Deployments
Blog

Observability ROI: Real Savings From Real Deployments

Observability can cut alert noise, speed up incident response, reduce downtime, and give engineers more time for planned work. LogicMonitor customers have used those gains to lower costs and make better infrastructure decisions.
September 9, 2026
Learn more
Is HTTPS the Answer to Man in the Middle Attacks?
Blog

Is HTTPS the Answer to Man in the Middle Attacks?

See how synthetic monitoring exposed a hidden HTTP redirect attack, and why HTTPS, HSTS, and delivery-path visibility keep your users safe from interception.
September 9, 2026
Learn more
Stale DNS Glue Records: How to Diagnose Parent-Authoritative Mismatches
Blog

Stale DNS Glue Records: How to Diagnose Parent-Authoritative Mismatches

Your authoritative servers return the right IP, but users still hit the old one. Here’s how to find stale glue records and fix the parent-zone referral.
September 9, 2026
Learn more