Subdomain Takeover & Dangling CNAME Detection
What This Check Does
The Dangling CNAME Detection check identifies CNAME records in your DNS zone whose target hostnames do not resolve to any IP address. These 'dangling' CNAMEs often point to decommissioned services, expired cloud resources, or deleted third-party platforms — and they represent a serious security vulnerability known as subdomain takeover.
DNS Spy resolves the target of every CNAME record in your zone. If any target fails to resolve, the CNAME is flagged as dangling.
Why It Matters
Subdomain takeover is one of the most exploited DNS vulnerabilities today. When a CNAME record points to a service that no longer exists (e.g., a deleted Heroku app, an expired Azure resource, or a decommissioned S3 bucket), an attacker can claim that resource and serve their own content on your subdomain. This allows them to host phishing pages, steal cookies, or serve malware — all under your domain's trusted reputation.
Dangling CNAMEs are particularly dangerous because they often go unnoticed for months or years. Teams decommission services without cleaning up DNS records, creating silent vulnerabilities. Regular automated scanning is essential to catch these before attackers do.
What Is Subdomain Takeover?
Subdomain takeover is an attack where someone gains control of the content served on your subdomain by claiming a third-party resource your DNS still points to. The vulnerability lives in the gap between your DNS zone and the services it references: DNS says blog.example.com is old-app.herokuapp.com, but nobody owns old-app.herokuapp.com anymore — so an attacker registers it, and your subdomain is now theirs. No account of yours is breached, no server of yours is touched; the attacker simply picks up a name your DNS was still vouching for.
How a Subdomain Takeover Attack Works
Discovery — attackers continuously enumerate subdomains of target organizations (certificate transparency logs make this trivial) and check which CNAMEs point to unclaimed or deprovisioned third-party resources.
Claim — on the third-party platform, the attacker registers the resource name your CNAME references: the deleted app name, the released bucket name, the expired site handle.
Serve — your subdomain now resolves to content the attacker controls. Many platforms will even issue them a valid SSL certificate for your subdomain automatically.
Exploit — phishing pages under your trusted domain, cookie theft when session cookies are scoped to the parent domain, bypass of CORS and content-security policies that trust your subdomains, and malware distribution with your reputation as cover.
Commonly Vulnerable Services
Any platform where resource names are claimable by new customers can enable a takeover when your CNAME outlives the resource: cloud storage buckets, PaaS app hosts, static-site and pages services, CDN endpoints, e-commerce storefronts, help-desk and status-page providers. The common thread is not any single vendor — it is the orphaned DNS record. Some platforms have added domain-verification defenses over the years; many have not, and new services appear faster than defenses do.
How to Prevent Subdomain Takeover
Make DNS cleanup part of decommissioning: the ticket that shuts a service down should include removing its DNS records, in that order — remove the record first, then release the resource.
Inventory your zone: you cannot clean up records you don't know exist. Complete record discovery — via provider sync or zone transfer — is the prerequisite.
Scan continuously: every CNAME target should resolve, every cycle. A target that stops resolving is a takeover window that has just opened — the alert needs to reach you before it reaches an attacker's enumeration script.
Good vs. Bad Configuration
Bad Configuration
blog.example.com CNAME old-app.herokuapp.com — The Heroku app was deleted months ago, but the CNAME still exists. An attacker could create a new Heroku app with this name and take over your subdomain.
Good Configuration
All CNAME records point to active, resolvable targets. When services are decommissioned, the corresponding DNS records are promptly removed. Example: blog.example.com CNAME example.ghost.io — The Ghost blog is active and resolving.
How DNS Spy Monitors This
DNS Spy's enterprise monitoring resolves the target of every CNAME record in your zone during each cycle. If any target fails to resolve, an alert is triggered immediately with details about the dangling CNAME and the risk it poses. This continuous scanning catches dangling CNAMEs as soon as they appear, giving you time to remediate before attackers can exploit them.
