Blog
Subdomain Takeover: The Dangling CNAME Risk Nobody Checks
You deleted a staging app 18 months ago. You forgot to remove the DNS record.
Someone else just claimed that app name on Heroku. They're now serving content on staging.yourdomain.com.
That's a subdomain takeover. It's more common than most people think.
How It Happens
The pattern is always the same:
- You create a subdomain pointing to an external service (Heroku, GitHub Pages, S3, Netlify, Vercel, Azure)
- You delete the service or project
- You forget to delete the DNS record
- The CNAME is now pointing to an unclaimed name on that service
- An attacker claims the name
- Your subdomain now serves their content
Why This Is Serious
The content serves from your domain. Browsers show your domain in the URL bar. SSL certificates cover your subdomain.
Users see your domain. They trust it. The attacker controls what they see.
This is used for phishing, credential harvesting, and malware distribution — all under your brand.
The Services Most Exploited
- GitHub Pages — most common
- AWS S3 — unclaimed buckets
- Heroku — deleted apps
- Netlify — deleted sites
- Azure Web Apps — deprovisioned apps
- Fastly — deleted services
How to Find Your Dangling Records
Run DomainPreflight Dangling Records on your domain.
It scans certificate logs to discover your subdomains, then checks each CNAME against a feed of known takeover fingerprints.
Any subdomain pointing to an unclaimed service shows as a risk — with a direct link to claim it or a fix recommendation.
The Fix
Delete the DNS record. That's it.
If you still need the subdomain, recreate the service first. Then the CNAME points to something you own.
If you're not sure whether the CNAME is still needed — delete it. DNS records are easy to add back. Subdomain takeovers are hard to recover from.
Scan your subdomains
Open Dangling Records →FAQ
What is a subdomain takeover?
When a CNAME points to a deleted external service, an attacker can claim that service and serve content on your subdomain.
How do I check if I have dangling DNS records?
Run DomainPreflight Dangling Records — it discovers your subdomains via certificate logs and checks each one for takeover risk.
Which services are most commonly exploited?
GitHub Pages, AWS S3, Heroku, Netlify, and Azure are the most common targets for subdomain takeover.
How do I fix a dangling CNAME?
Delete the DNS record. If you still need the subdomain, recreate the service first so the CNAME points to something you control.
Can this happen to a root domain?
No — subdomain takeover requires a CNAME, which cannot be used at the root domain. Only subdomains are at risk.