What is a dangling DNS record?
A dangling DNS record is a DNS entry that points to a resource that no longer exists. The most dangerous variant involves CNAME records pointing to cloud services — Heroku apps, AWS S3 buckets, GitHub Pages, Zendesk portals, Shopify stores, and dozens of other platforms.
The pattern is simple and extremely common: a developer sets up blog.company.com as a CNAME pointing to their Heroku app. Later, the Heroku app is deleted — but no one remembers to delete the DNS record. The CNAME remains, pointing to an app that no longer exists.
How the subdomain takeover works
Most cloud platforms use globally unique app names or bucket names within a shared namespace. When a Heroku app called company-blog.herokuapp.com is deleted, that name becomes available for anyone to register.
An attacker who notices the dangling CNAME at blog.company.com → company-blog.herokuapp.com simply registers a new Heroku app with the name company-blog. Now:
blog.company.comresolves to the attacker's Heroku app- Visitors to
blog.company.comsee content controlled by the attacker - The attacker can serve phishing pages, malware downloads, or fake login forms
- The content appears to be served from
company.com— a trusted domain
The attacker can also obtain a valid TLS certificate for the subdomain, because Let's Encrypt and other CAs verify domain control via DNS or HTTP — both of which the attacker now controls. The browser shows a green padlock on the attacker's page.
Beyond serving malicious content, subdomain takeover enables:
- Cookie theft — If the domain uses cookies with the
domain=.company.comflag, the attacker's subdomain can read those cookies - Bypass of Content Security Policy — CSP policies often whitelist subdomains of the main domain
- OAuth abuse — Services that authorize redirects to any subdomain of a domain can be abused to redirect OAuth tokens to the attacker's subdomain
Real cases of subdomain takeover
This vulnerability is not theoretical — it has been found at some of the largest organizations on the internet:
- Microsoft — Security researchers found dangling DNS records on multiple Microsoft-owned domains pointing to unclaimed Azure services. Microsoft's bug bounty program now offers significant rewards for subdomain takeover reports.
- Snapchat, Lyft, and other major tech companies — Found to have vulnerable subdomains pointing to deleted Heroku apps, S3 buckets, and other cloud resources. Most were discovered by independent researchers and responsibly disclosed.
- UK Government domains — A 2020 audit of UK government subdomains found multiple domains with dangling CNAMEs pointing to cloud services that no longer existed.
Which cloud services are most commonly exploited
The following services are frequently involved in subdomain takeover reports because they allow users to claim custom subdomains:
- Heroku (
*.herokuapp.com) - AWS S3 (
*.s3.amazonaws.com,*.s3-website-*.amazonaws.com) - GitHub Pages (
*.github.io) - Netlify (
*.netlify.app) - Shopify (
*.myshopify.com) - Zendesk (
*.zendesk.com) - Ghost (
*.ghost.io) - Azure (
*.azurewebsites.net,*.cloudapp.net)
How to find dangling CNAMEs in your DNS zone
The process involves two steps: enumerate all CNAME records in your DNS zone, then verify that each target is a resource you control.
Many cloud platforms return a distinctive error page when a custom domain is claimed but no app is configured. For example, Heroku returns "No such app" and GitHub Pages returns "There isn't a GitHub Pages site here." These responses confirm the target is available for registration.
Automate your audit. Tools like subjack, nuclei, and dnsReaper can scan your entire DNS zone for dangling records against known vulnerable services. Consider running these quarterly.
How to fix dangling DNS records
The fix is straightforward: delete the CNAME record from your DNS zone. If the subdomain needs to continue pointing somewhere, update it to point to an active resource you control.
As a policy change: require that DNS records are cleaned up as part of the offboarding process whenever a cloud service or resource is decommissioned. This is a process and policy problem as much as a technical one.