Dangling CNAMEs and Subdomain Takeover Risk Across the Global DNS

Every CNAME record is a promise: this domain name points somewhere else, and that somewhere else will answer. But what happens when the destination disappears? I processed 201,815,332 CNAME records from Rapid7's Project Sonar dataset and found that 13,891,722 of them, 6.88%, point to cloud provider services. Of those, 3,272,017 point to platforms on which subdomain takeover is a documented failure mode. Read that as a measure of attack surface, not of exposure. The scan matched CNAME targets against provider patterns; it did not test whether any given target was dangling, and it could not test whether a dangling name was still claimable. That denominator therefore includes live resources, verified domains, and reserved or unavailable identifiers alongside genuinely orphaned records. How many of the 3.27 million are actually vulnerable is a number I cannot give you from this data.

Historical evidence limits (reviewed September 2026): The counts below are retained as reported for the November 27, 2020 snapshot. A reproducible extraction manifest, pattern definitions, and deduplication code are not published with this article, so these totals have not been independently reconstructed for this update. They are provider-pattern observations, not a current list or count of vulnerable hosts.

How I Measured This

The data comes from Rapid7's Project Sonar forward DNS (FDNS) CNAME snapshot from November 27, 2020. Project Sonar performs internet-wide surveys by resolving DNS records across the entire IPv4 space and publicly registered domains. The CNAME dataset captures every canonical name record observed during these scans.

I built a pattern-matching pipeline that categorizes each CNAME target against known cloud provider domains. When a CNAME record points to shops.myshopify.com, herokuapp.com, or s3-website-us-east-1.amazonaws.com, the pipeline flags it and classifies the risk level based on the target platform's claim model. The full scan covered 29 cloud providers and platform services, from major infrastructure like AWS and Azure down to niche services like Surge.sh and Cargo.

This is not a vulnerability scan. I did not attempt to claim any domains or verify which specific CNAMEs are currently exploitable. What the data reveals is the attack surface: the total number of CNAME records pointing to services where subdomain takeover is architecturally possible. For the port-level view of that same attack surface, see my analysis of common service exposure across IPv4, and for the device side, my look at unsecured IoT protocols like MQTT and Telnet left open on the public internet.

What Makes a Dangling CNAME Dangerous

A dangling CNAME is a DNS record that points to a resource that no longer exists. The classic scenario plays out like this: a company spins up a Heroku app at myapp.herokuapp.com, creates a CNAME from app.example.com pointing to it, then later deletes the Heroku app but forgets to remove the CNAME record. Now app.example.com still resolves. It follows the CNAME chain to myapp.herokuapp.com, but nobody owns that Heroku endpoint anymore.

A takeover is possible only if the provider lets a different account attach the abandoned resource or hostname without proving domain control. The provider name and an error response alone are insufficient. Current GitHub Pages verification controls, for example, can prevent another user from attaching a verified name. Treat the Heroku sequence as a historical illustration of the failure mode, not a verified current claimability test.

The severity depends entirely on the platform. Some services let anyone claim any unclaimed name on a first-come-first-served basis. Others tie names to verified account ownership. This distinction is what separates a theoretical risk from a practical exploit.

The Scale of the Problem

Across 201 million CNAME records, here is how the 13.9 million cloud-pointing records break down by provider:

The concentration is striking. Just three providers, WordPress.com, Shopify, and Heroku, account for over 80% of all cloud-pointing CNAMEs. The most popular CNAME targets tell the story even more clearly: 4.6 million records point to lb.wordpress.com, 2.7 million to shops.myshopify.com, and 1.8 million to us-east-1-a.route.herokuapp.com.

Not All Cloud CNAMEs Are Equal

The original analysis grouped the 13.9 million provider-pattern matches into three tiers. Those labels are retained to explain the historical classification; they are not current provider vulnerability ratings or verified claimability results.

Historical high tier (3,272,017 records): The original pattern map put services such as Heroku, GitHub Pages, AWS S3, and Azure App Service in this group. A match does not establish that a resource is absent, that its identifier can be reused, or that a different account can attach the custom hostname.

Historical medium tier (4,939,187 records): These patterns were associated with services including Shopify, CloudFront, and Fastly. The scan did not test their account or domain-verification controls, so the count cannot quantify how much harder a takeover would be.

Historical low tier (5,680,518 records): This was the WordPress.com pattern count. Its size describes observed references, not proof that every record was active or that takeover was impossible.

The 3.27 million figure is the original high-tier pattern count. Current verification, identifier reservation, endpoint routing, and resource state all affect claimability. None of those conditions was measured by counting CNAME patterns.

Ghost Services: When Platforms Die But DNS Lives On

Some of the most interesting findings involve services that no longer exist. Two examples stand out.

Posterous: The historical snapshot reported 26,289 CNAMEs targeting posterous.herokuapp.com after the service had closed. The scan did not verify the endpoint’s ownership or claimability. A persistent reference is a reason to investigate lifecycle management, not proof of 26,289 takeable domains.

CodePlex: The report counted 41,731 CNAMEs targeting codeplexarchive.azurewebsites.net, an archive-related hostname. Whether a specific custom name is claimable depends on resource and verification state. Azure’s guidance describes protections such as App Service domain-verification TXT records.

These ghost services illustrate the fundamental problem: DNS records outlive the infrastructure they point to. Platform shutdowns, company acquisitions, and service deprecations leave behind a trail of dangling CNAMEs that only grows over time. Without active DNS lifecycle management, every decommissioned service creates potential takeover targets.

The TLD Perspective

The following table distributes the observed provider-pattern matches by TLD. These are record counts, not normalized adoption rates or verified takeover exposure:

The .com entries account for about 87% of the reported provider-pattern matches. Without comparable scan coverage and domain denominators, differences between TLDs cannot establish which populations are more cloud-dependent or vulnerable.

The .jp row has the second-largest reported count, at 209,419. The scan does not establish the business types or motivations behind those references. Explore current TLD-level findings on the security dashboard.

How Subdomain Takeover Actually Works

To understand why 3.27 million provider-pattern CNAMEs matter, let me walk through the actual attack for three of the most common targets.

Heroku (2.1 million CNAMEs combined): A missing-app response is an investigation lead, not a completed takeover test. Heroku’s custom-domain documentation requires attaching the hostname to an app and using its assigned DNS target. The historical shortcut of creating a similarly named app does not establish that an existing custom CNAME will route to it.

AWS S3 Website Hosting (32,888 CNAMEs): For a custom hostname such as assets.example.com, S3 uses the requested hostname to select the bucket. AWS documents that the bucket name must match the custom hostname. A stale alias and a missing matching bucket can create risk, but a count of S3 target patterns does not prove that those conditions hold.

GitHub Pages (215,373 CNAMEs): An absent site does not establish that the account, repository, or custom hostname can be claimed. GitHub’s domain-verification controls can prevent another account from attaching a verified domain. Check verification and resource ownership rather than assuming a 404 proves takeover.

In each case, the attacker never touches the victim's DNS. They exploit the gap between what the CNAME promises and what exists at the destination. You can use the DNS Inspector to check what CNAME records exist for any domain and trace where they resolve.

Why This Keeps Happening

The root cause is a lifecycle management gap. DNS records are created as part of provisioning a service but are rarely included in the decommissioning checklist. Several factors make this worse:

Organizational silos. The team that manages DNS is often different from the team that manages cloud infrastructure. When a developer shuts down a staging environment on Heroku, they do not have access to (or awareness of) the DNS records pointing to it.

No expiration mechanism. DNS records have a TTL for caching, but no concept of an expiration date. A CNAME created in 2015 for a proof-of-concept app will remain in the zone file indefinitely unless someone actively removes it.

Scale obscures risk. A large organization might have thousands of DNS records across dozens of zones. Identifying which CNAMEs point to active versus decommissioned services requires cross-referencing DNS data with infrastructure inventories, a task that most teams never automate.

Mergers and acquisitions. When companies are acquired, their DNS zones are often inherited wholesale. The acquiring company may not even know what half the records point to, much less which services are still active.

Free-tier churn. Many of the high-risk CNAMEs point to free-tier services that were created for experiments, hackathons, or personal projects and then abandoned. The low cost of creation means there is no financial incentive to clean up.

What Domain Owners Should Do

If you manage DNS for any organization, here are concrete steps to reduce your subdomain takeover surface:

Audit your CNAME records regularly. Export your zone files and check every CNAME target. If the destination returns an error page, a default parking page, or does not resolve at all, that record is a candidate for removal. Automate this check on a monthly schedule.

Remove DNS records before decommissioning services. This should be step one in any service teardown checklist, not an afterthought. Delete the CNAME first, use the DNS propagation checker to sample authoritative and recursive answers, allowing the previous TTL and relevant cache behavior before releasing the resource, then delete the cloud resource.

Use domain verification where available. Many cloud providers now offer DNS TXT record verification for custom domains. Prefer providers that require you to prove domain ownership before they will serve content on your subdomain.

Monitor for takeover indicators. Set up alerts for any of your subdomains that start returning unexpected content, error pages from cloud providers you do not use, or HTTP responses with headers from unfamiliar platforms.

Consolidate DNS management. If your organization has DNS records spread across multiple providers and registrars, consolidate them. A single pane of glass makes it much easier to audit and clean up stale records.

Consider CAA records, but do not mistake them for a takeover defence. Certificate Authority Authorization records restrict which CAs may issue for a name; they do not authenticate the requester. RFC 8659 puts it plainly: conformity with a CAA record is "a necessary, but not sufficient, condition" for issuance. An attacker who controls the hostname can satisfy domain validation, so if they go to a CA you have authorized, a normal issue allowlist does not stop them. CAA narrows the set of CAs that could mis-issue, and a issue ";" record forbidding all issuance genuinely does block certificates, as do account-binding parameters where your CA supports them. Ordinary CAA deployment is not in that category.

The 3.27 million provider-pattern CNAMEs I found in this analysis represent just the cloud-pointing subset of a much larger problem. Keep DNS records tied to resource ownership and teardown procedures so stale references can be found and removed.