Dangling DNS Records Explained
What dangling DNS records are, how they accumulate, and why they matter beyond subdomain takeover.
Core Concept
A dangling DNS record is a record that still exists and resolves to something, but the resource it points to no longer belongs to the organization that created the record.
This can happen with A records pointing to deallocated IPs, or more commonly with CNAME records pointing to third-party services that have since been cancelled or deleted.
How Dangling Records Accumulate
- A cloud resource, load balancer, or storage bucket is deleted without removing its DNS record
- A vendor relationship ends but the CNAME pointing at that vendor's infrastructure remains
- An IP address is released back to a hosting provider and later reassigned to a different customer
- A project is sunset and the team responsible moves on without a DNS cleanup step
Slow Accumulation
Dangling records rarely appear all at once — they build up gradually over years as infrastructure changes and DNS cleanup gets deprioritized.
Beyond Subdomain Takeover
Subdomain takeover is the most discussed consequence of dangling DNS, but it isn't the only one. A dangling record pointing to a reassigned IP address can silently route traffic — and potentially sensitive requests — to infrastructure controlled by an unrelated third party.
Dangling records also complicate incident response and asset inventory, since they represent infrastructure that appears to exist in DNS but no longer maps to anything the organization actually controls.
Detecting Dangling Records
- Cross-reference subdomain scan results against an internal asset inventory
- Flag hosts marked dead that still carry a CNAME pointing to a third-party platform
- Check whether resolved IPs still belong to expected hosting providers
Fixing and Preventing Dangling Records
The fix itself is usually simple: remove or repoint the record once the underlying resource is confirmed gone. The harder part is prevention, since it requires DNS cleanup to become a standard step in decommissioning workflows rather than an afterthought.
Some organizations solve this by tying DNS record ownership to infrastructure-as-code, so deleting a resource in code automatically removes its associated DNS entry.
Real-World Implementation
Dangling DNS review is a recurring line item in cloud security posture assessments, particularly for organizations with high infrastructure turnover or many independent teams managing their own DNS entries.
Continuous monitoring pipelines increasingly re-scan known subdomains on a schedule specifically to catch newly dangling records before they can be exploited.
Common Mistakes to Avoid
- Deleting cloud resources without checking for associated DNS records first.
- Treating DNS cleanup as optional during vendor offboarding.
- Assuming dangling records are only a risk for CNAME-based services.
- Not maintaining an internal map between DNS records and the resources they point to.
- Overlooking dangling records during infrastructure audits focused only on active systems.
- Failing to re-scan periodically, allowing new dangling records to go unnoticed.
- Assuming a small DNS zone file means low dangling-record risk.
- Ignoring third-party vendor transitions as a common trigger for dangling records.
Best Practices Checklist
- Make DNS record removal part of every resource decommissioning checklist.
- Tie DNS entries to infrastructure-as-code where possible for automatic cleanup.
- Maintain a living inventory mapping DNS records to their intended resources.
- Re-scan known subdomains on a recurring schedule to catch new dangling records.
- Review dead subdomains from every scan specifically for lingering third-party pointers.
- Assign clear ownership for DNS hygiene across teams and vendors.
- Audit vendor offboarding processes for a required DNS cleanup step.
Frequently Asked Questions
Is every dangling record exploitable?
No — exploitability depends on whether the pointed-to resource name can actually be re-claimed by a third party, which varies by platform.
Are A records or CNAME records more commonly dangling?
CNAME records pointing to third-party services are the most frequently discussed case, though A records to reassigned IPs carry similar risk.
How do I remove a dangling record?
Delete or repoint it through your DNS provider once you've confirmed the underlying resource no longer belongs to your organization.
Can automation prevent dangling records entirely?
It significantly reduces the risk when DNS entries are tied to infrastructure-as-code, though manually created records still need periodic review.
Do dangling records affect DNSSEC-signed zones differently?
The dangling-record risk itself is independent of DNSSEC, which secures record integrity rather than validating what a record points to.
How often should I audit for dangling records?
Regularly, and especially after any vendor transition, infrastructure migration, or project decommissioning.
Can a subdomain scan find all dangling records?
It can surface dead subdomains as candidates, but confirming a record is genuinely dangling and exploitable requires further investigation.
Find Dead Subdomains Worth Reviewing
Scan a domain to surface dead hosts that may still carry dangling DNS records.
Launch Tool →