Dangling DNS Records and Subdomain Takeover Risk
How an orphaned CNAME pointing to a deprovisioned service can let an attacker claim your subdomain.
Core Concept
A dangling DNS record points to a resource — a cloud service, a third-party platform — that no longer exists or has been deprovisioned, while the DNS record itself remains in place.
This creates an opportunity for subdomain takeover: an attacker who claims the now-available resource inherits control over anything pointing to it via the stale DNS record.
How Takeovers Happen
The pattern typically follows a predictable sequence.
- A CNAME points a subdomain to a third-party service
- The service is later deprovisioned without updating DNS
- An attacker registers the same resource name on that service
Common Vulnerable Services
Cloud storage buckets, static site hosts, and SaaS platforms with vanity subdomains are among the most frequently exploited takeover vectors.
Consequences of a Successful Takeover
Once claimed, the subdomain is fully under the attacker's control, inheriting the trust of the parent domain.
- Hosting phishing content under a trusted brand's subdomain
- Bypassing certain domain-based security checks
- Damaging brand reputation and potentially SEO standing
Finding Dangling Records
Identifying vulnerable records requires systematically checking whether each CNAME target still resolves to an active resource.
Automated scanners maintain fingerprint databases of known 'service not found' responses across common cloud platforms to flag likely takeover candidates.
Fingerprint Matching
Specific error messages from deprovisioned cloud resources serve as reliable fingerprints for automated dangling record detection.
Preventing Subdomain Takeover
A few practices meaningfully reduce this risk.
- Remove DNS records immediately when decommissioning a service
- Regularly audit all subdomains against their actual live status
- Maintain a central inventory linking subdomains to their owning teams
Real-World Implementation
Subdomain takeover is a well-established finding category in bug bounty and security research.
- Bug bounty programs frequently rewarding takeover discoveries
- Automated continuous monitoring tools scanning for dangling records
- Security teams integrating decommission checklists into DevOps workflows
Because the underlying cause is organizational rather than technical, preventing takeovers is as much about process discipline as it is about tooling.
Common Mistakes to Avoid
A few recurring mistakes leave organizations exposed to subdomain takeover.
- Leaving a CNAME in place after decommissioning the third-party service it pointed to.
- Assuming subdomain takeover risk only applies to obscure or unused subdomains.
- Failing to include DNS record cleanup as part of a standard decommissioning checklist.
- Not maintaining a central inventory linking subdomains to their owning teams.
- Overlooking dangling records during routine security audits.
- Assuming subdomain takeover risk only applies to a narrow set of well-known cloud services.
- Overlooking internal or lesser-known third-party services with similar takeover risk.
- Failing to prioritize remediation based on the sensitivity of the affected subdomain.
- Overlooking that some cloud providers changed their error responses, breaking older detection signatures.
- Assuming a single scan catches every dangling record across a large, dynamic organization.
- Failing to integrate takeover scanning into infrastructure decommissioning workflows directly.
- Overlooking internal ticketing systems that could better track service decommissioning across teams.
Best Practices Checklist
These practices meaningfully reduce subdomain takeover risk.
- Treat DNS record removal as a mandatory step whenever decommissioning any service.
- Maintain a central inventory linking every subdomain to its owning team and purpose.
- Run automated scans specifically for dangling records on a regular schedule.
- Include subdomain takeover checks in routine security audits, not just one-time reviews.
- Respond quickly to any confirmed dangling record, since exploitation windows can be short.
- Extend takeover scanning coverage beyond the most commonly cited vulnerable services.
- Prioritize remediation for dangling records on subdomains handling sensitive functions.
- Maintain an updated fingerprint database as new vulnerable service patterns emerge.
- Keep detection signatures current, since cloud providers periodically change their error responses.
- Run takeover scanning on a recurring basis rather than treating it as a one-time exercise.
- Integrate automated takeover scanning directly into infrastructure decommissioning workflows.
- Use a centralized ticketing process to track service decommissioning across all teams consistently.
Frequently Asked Questions
Frequently asked questions about dangling DNS records and subdomain takeover.
What makes a DNS record 'dangling'?
It's dangling when it still points to a resource — like a cloud service or hosting platform — that no longer exists or has been deprovisioned.
How does an attacker actually take over a subdomain?
By registering the same resource name on the third-party service that the dangling record still points to, effectively claiming the subdomain.
Which types of services are most commonly exploited this way?
Cloud storage buckets, static site hosts, and SaaS platforms offering vanity subdomains are among the most frequently exploited.
Why is a taken-over subdomain particularly dangerous?
It inherits the trust of the parent domain, making phishing content served from it far more convincing than content on an unrelated domain.
How can I check if my organization has any dangling records?
Automated scanning tools can check whether each subdomain's CNAME target still resolves to an active resource, flagging likely takeover candidates.
Is subdomain takeover risk limited to major cloud providers?
No — many lesser-known third-party services carry similar risk, so scanning coverage shouldn't be limited to only the most commonly cited platforms.
Should all dangling records be treated with equal urgency?
No — prioritizing based on the sensitivity of the affected subdomain, like one handling authentication, makes remediation efforts more effective.
How do fingerprint databases for takeover detection stay current?
They require ongoing maintenance as cloud providers change their error responses and new vulnerable service patterns are discovered.
Do cloud providers change their error responses over time?
Yes — periodic changes can break older detection signatures, making it important to keep scanning tools and fingerprints updated.
Should takeover scanning be integrated into decommissioning workflows?
Yes — catching it automatically at decommission time is far more reliable than hoping a later periodic scan catches the gap.
Does a centralized ticketing process help prevent dangling records?
Yes — consistent, tracked decommissioning across all teams closes a major gap that ad hoc processes tend to leave open.
Check for Dangling Records
Run a DNS analysis to check for dangling records that could enable subdomain takeover.
Launch Tool →