How to Detect a Dangling CNAME Before an Attacker Does
Subdomain takeover is one of the quietest ways a company loses control of part of its own domain. It starts with a small, easy-to-miss DNS mistake: a CNAME record left pointing at a resource that no longer exists. Here is exactly how that happens, and how to find it before someone else does.
What a dangling CNAME is
A CNAME record maps one hostname to another, commonly used when a company points a subdomain at a third-party service, such as blog.example.com pointing to a hosting platform's domain. When the team stops using that service, whether by canceling the account, deleting the project, or letting a trial expire, they often forget to also remove the CNAME record. The DNS record keeps pointing at the third-party domain, but the specific resource it once resolved to no longer exists there. That leftover, pointing-at-nothing record is a dangling CNAME.
How subdomain takeover works technically
Many hosting and cloud platforms let anyone claim a resource name, such as a project or app name, on a first-come basis. If a dangling CNAME still points to oldproject.hostingplatform.com, and that project name is now unclaimed, an attacker can simply sign up for the same platform and register a new project using that exact name. The moment they do, requests to the victim's subdomain resolve to infrastructure the attacker controls, since DNS still trusts the original CNAME.
From there, the attacker can serve arbitrary content from what looks, to any visitor or automated system, like a legitimate subdomain of the victim's own domain. This can be used for phishing, session cookie theft if cookies scope broadly enough, or simply reputational damage.
Common vulnerable services
| Service pattern | Fingerprint example | Risk |
|---|---|---|
| Static site hosts | CNAME to a hosting domain, custom domain not configured on the platform side | High, page shows a clear "not found" or setup page |
| PaaS app platforms | CNAME to an app subdomain of the platform, app deleted | High, error page often names the platform directly |
| Cloud object storage | CNAME to a storage bucket domain, bucket deleted or never created | High, bucket names are frequently guessable or reusable |
| CDN and edge platforms | CNAME to a CDN distribution, distribution deleted | Medium, depends on platform's reclaim policy |
| Help desk and support tools | CNAME to a support subdomain, account canceled | Medium, often used for convincing phishing pages |
Step-by-step manual detection
- Enumerate all subdomains for the domain, including historical ones that may still have live DNS records.
- Resolve each subdomain's DNS records and note which ones are CNAMEs pointing to a third-party domain rather than an IP address.
- Visit each CNAME target in a browser or with a simple request, and look for known "not found," "no such app," or "domain not claimed" error pages, which are strong signals of an unclaimed resource.
- Cross-reference against a known fingerprint list for the specific service, since error page wording varies by platform and changes over time.
- Verify before reporting or reclaiming, since a slow-loading or temporarily misconfigured service can occasionally resemble a dangling state without actually being exploitable.
Do not attempt to actually claim a vulnerable resource
Proving a dangling CNAME is exploitable by registering the resource yourself, even briefly, can cross legal and ethical lines depending on scope and authorization. Document the finding and report it through the appropriate channel instead.
How automated tools fingerprint this
Automated takeover detection works by maintaining a database of known vulnerable service patterns: the CNAME target domain pattern for each platform, paired with the specific response text or status code that platform returns for an unclaimed resource. A scanner resolves each subdomain's CNAME chain, matches the target against this fingerprint database, and where there is a match, sends a lightweight request to check for the telltale unclaimed-resource response before flagging it.
Subdomain Finder checks for this automatically
Every scan from Subdomain Finder checks discovered subdomains against known vulnerable service fingerprints and flags dangling CNAME records as part of the standard report, no separate tool required.
Try a scan free →Frequently asked questions
What is a dangling CNAME?
A dangling CNAME is a DNS record that still points to a third-party service, such as a cloud hosting platform, after the resource on that service has been deleted or expired, leaving the hostname unclaimed and available for anyone to register.
How does subdomain takeover work?
An attacker finds a subdomain with a CNAME pointing to a deleted or unclaimed resource on a third-party service, then registers that same resource name on the service themselves, causing the victim's subdomain to now serve content the attacker controls.
Which services are commonly vulnerable to subdomain takeover?
Services that let users claim a subdomain-like resource name are the most common pattern, including certain configurations of GitHub Pages, Heroku, AWS S3, Azure, and various CDN and hosting platforms, when a CNAME is left pointing at a deleted resource.
Does Subdomain Finder detect subdomain takeovers?
Yes. Subdomain Finder checks discovered subdomains against known vulnerable service fingerprints and flags CNAME records pointing at unclaimed resources as part of its standard scan.