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 are high-risk records pointing to platforms where anyone could potentially claim the unconfigured endpoint and hijack the subdomain. That is over three million doors left unlocked across the global DNS.

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.

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.

An attacker can create a new Heroku app, claim the `myapp` name, and suddenly they control what `app.example.com` serves. They can host phishing pages, steal cookies scoped to `example.com`, intercept OAuth callbacks, or serve malware — all under a legitimate-looking subdomain of the target organization.

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 headline number of 13.9 million sounds alarming, but the real risk picture is more nuanced. I categorized each provider into three risk tiers based on how their platform handles domain claims:

High risk (3,272,017 records): These are platforms where anyone can sign up and claim an unclaimed subdomain or endpoint name. Heroku is the poster child — if `myapp.herokuapp.com` is not taken, any Heroku user can create an app with that name. The same applies to GitHub Pages, AWS S3 buckets, Azure App Service, Elastic Beanstalk, Netlify, Pantheon, Surge.sh, and others. When a CNAME points to one of these services and the endpoint is unclaimed, subdomain takeover is straightforward.

Medium risk (4,939,187 records): These platforms have account-based ownership models that make takeover harder but not impossible. Shopify requires domain verification through your Shopify admin panel. CloudFront distributions are tied to AWS accounts. Fastly requires backend configuration. An attacker cannot simply claim a name — they need to exploit gaps in the verification process or find edge cases. The risk is real but requires more sophistication.

Low risk (5,680,518 records): WordPress.com dominates this category. Its custom domain system requires account-level domain verification, and the sheer volume of its CNAMEs (5.68 million) reflects the scale of WordPress-hosted sites rather than a security gap. Takeover is not practical under normal circumstances.

The critical number is 3.27 million. That is the count of CNAME records pointing to platforms where the takeover mechanism is well-documented, the tools are freely available, and the only barrier is whether someone has already claimed the endpoint.

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 was a blogging platform acquired by Twitter in 2012 and shut down on April 30, 2013. More than seven years after Posterous ceased to exist, 26,289 CNAME records still pointed to `posterous.herokuapp.com`. These domains followed a CNAME chain to a Heroku endpoint that could theoretically be claimed by anyone. Every one of those 26,289 domains was a potential subdomain takeover target — not because of any current misconfiguration, but because the platform they relied on disappeared and nobody cleaned up the DNS.

CodePlex was Microsoft's open-source hosting platform, shut down in December 2017. I found 41,731 CNAME records pointing to `codeplexarchive.azurewebsites.net`, the Azure-hosted archive that Microsoft maintained after shutdown. Since Azure App Service names follow a first-come-first-served model under `azurewebsites.net`, the fate of these records depends entirely on whether Microsoft continues to hold that specific Azure endpoint.

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 distribution of cloud-pointing CNAMEs across TLDs reveals where cloud infrastructure adoption is highest — and where the takeover surface is concentrated:

The .com dominance is expected — it accounts for 87% of all cloud-pointing CNAMEs. But some TLDs punch above their weight relative to their total zone size. The .io TLD, popular with tech startups and developer tools, shows up with nearly 52,000 cloud CNAMEs despite having a much smaller total domain count than .de or .uk. This makes sense: .io domains are disproportionately used by the exact kind of companies that deploy to Heroku, Netlify, and GitHub Pages — the high-risk providers.

Japan's .jp ranks second with over 209,000 cloud CNAMEs, reflecting the heavy adoption of WordPress.com and Shopify by Japanese businesses. You can explore TLD-level security data on the security dashboard to see how different zones compare across various risk dimensions.

How Subdomain Takeover Actually Works

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

Heroku (2.1 million CNAMEs combined): An attacker finds a CNAME record for `portal.victim.com` pointing to `victim-portal.herokuapp.com`. They visit the URL and get a Heroku "no such app" error page. They sign up for a free Heroku account, create an app named `victim-portal`, and add whatever content they want. Within minutes, `portal.victim.com` serves the attacker's content. No DNS changes needed — the victim's own CNAME does the routing.

AWS S3 Website Hosting (32,888 CNAMEs): A CNAME for `assets.victim.com` points to `victim-assets.s3-website-us-east-1.amazonaws.com`. The bucket has been deleted. The attacker creates a new S3 bucket named `victim-assets` in the us-east-1 region, enables static website hosting, and uploads their payload. The CNAME chain completes, and the attacker controls the subdomain.

GitHub Pages (215,373 CNAMEs): A CNAME for `docs.victim.com` points to `victim.github.io`. The GitHub repository or user account no longer exists. The attacker creates a GitHub account named `victim` (if available), enables GitHub Pages, and configures `docs.victim.com` as a custom domain. GitHub's verification process has improved over the years, but historically this was one of the most exploited takeover vectors.

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, wait for propagation, 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. While not directly related to CNAME takeover, Certificate Authority Authorization (CAA) records can prevent an attacker who takes over your subdomain from issuing TLS certificates for it, limiting the damage they can do.

The 3.27 million high-risk CNAMEs I found in this analysis represent just the cloud-pointing subset of a much larger problem. Every organization has stale DNS records. The question is whether you find them before an attacker does.