How is a dangling CNAME different from a broken one?

A broken CNAME points at a name that no longer resolves — you get NXDOMAIN and the subdomain is simply dead. A dangling CNAME is worse: it still resolves to a live cloud platform (GitHub Pages, an S3 bucket host, an Azure endpoint), but the specific account or resource behind it has been deleted. The platform answers with a 'no such site' page that says, in effect, 'this name is unclaimed.' Anyone who can create a resource with that name on the same platform inherits your subdomain. Dead is safe; dangling-but-claimable is the vulnerability.

What can an attacker actually do with a taken-over subdomain?

Serve content from blog.yourcompany.com under your real domain and your valid TLS certificate — the browser shows the padlock and the right hostname, so phishing pages look completely legitimate. They can also read any cookies scoped to the parent domain (set with `domain=.yourcompany.com`), bypass CSP and CORS rules that trust your own subdomains, and abuse the domain's reputation to get past email and link filters. A subdomain you forgot about becomes a trusted launch pad you no longer control.

We deleted the cloud resource. Are we safe now?

Not until you also remove the DNS record. Deleting the S3 bucket, the Heroku app, or the Azure endpoint is exactly what creates the dangling pointer — the CNAME in your zone now aims at an unclaimed name. The correct order is the reverse: remove or repoint the DNS record first, then deprovision the resource. If the record is already dangling, delete it from your zone now; that's the only thing that closes the window.

Views: 7

Subdomain Takeover: Find Dangling DNS Records

Subdomain Takeover: a CNAME points to a deprovisioned cloud resource anyone can re-register. Spot dangling DNS in 4 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A subdomain like status.example.com or docs.example.com still has a DNS record, but the thing it points to is gone — a cloud app you decommissioned, a SaaS trial that lapsed, a CDN distribution you tore down. The record didn’t get cleaned up. It now points at a name that anyone can claim, and whoever claims it serves content from your domain, with your name in the address bar.

Symptoms

A CNAME or ALIAS points at a third-party platform (*.github.io, *.s3.amazonaws.com, *.herokudns.com, *.azurewebsites.net, *.cloudfront.net) but the page shows a platform error like “There isn’t a GitHub Pages site here” or “NoSuchBucket.”
An old subdomain from a retired project, marketing campaign, or vendor still resolves.
A security scanner or bug bounty report flagged a “dangling” or “claimable” record.
The subdomain returns a 404 from the platform, not from your own server.

What a Dangling DNS Record Actually Is

DNS records outlive the things they point to. You spin up a docs site on a hosting platform, add docs.example.com CNAME your-project.platform.io, and it works. Months later the project is shut down and the hosting account deleted — but the CNAME in your zone is still there, faithfully pointing at your-project.platform.io. That target name no longer belongs to anyone.

Here’s the part that turns housekeeping into a security hole: most cloud platforms let you claim a resource name on a first-come basis. The attacker registers your-project on the same platform, and because your CNAME still points there, docs.example.com now serves their content — under your domain, often with a TLS certificate they can provision for free because they can prove control of the subdomain. The browser shows a valid padlock and your hostname. It is, from the visitor’s point of view, indistinguishable from your real site.

This isn’t theoretical or new. The technique was documented by security researcher Frans Rosén and popularized by Detectify back in 2014; the community-maintained can-i-take-over-xyz project now catalogs the specific “unclaimed” fingerprints for over a hundred services. The reason it persists is mundane: deprovisioning a resource and cleaning up its DNS are two different tickets, and the second one gets forgotten.

Top 3 Causes

Decommissioned cloud resource, surviving CNAME — The classic case. A static site, app, or bucket gets deleted but its DNS record stays. The fingerprint is a platform-generated error page (not your own 404) at a subdomain that CNAMEs to that platform. If the platform lets a new account claim that resource name, the subdomain is takeable.
Expired SaaS or vendor integration — A help desk, status page, email marketing, or landing-page vendor gave you a CNAME to set. You stopped paying; they freed the resource; your record still points at it. These are easy to miss because the subdomain often has a memorable marketing name (help., careers., go.) and nobody owns it after the campaign ends.
Dangling NS delegation — Rarer but more dangerous: a subdomain is delegated (NS records) to a managed DNS zone that was later deleted at the provider. If an attacker can recreate that zone on the same provider, they control all records under the subdomain, not just one name.

Diagnose with DechoNet

DNS Check shows the exact CNAME/ALIAS/NS target for the subdomain. If it points at a third-party platform hostname, note the platform — that’s the service you need to check for a claimable resource. A target that resolves but isn’t yours is the warning sign.
HTTP Check fetches the subdomain and shows the response. A platform error body (“NoSuchBucket,” “There isn’t a GitHub Pages site here,” “404 Not Found · Fastly”) coming back over the third-party host — rather than your own server’s 404 page — is the fingerprint of a dangling, potentially claimable record.

Resolution Checklist

Inventory every subdomain that CNAMEs, ALIASes, or NS-delegates to a third party. These are the only records that can dangle — A/AAAA records to your own infrastructure can’t be claimed by a stranger.
For each, fetch the subdomain and read the body. A platform “unclaimed/no such resource” message is the red flag; your own application’s 404 is fine.
Cross-check the fingerprint against the can-i-take-over-xyz database to confirm whether that platform actually allows re-claiming the freed name (some now bind names to accounts and are not takeable).
Fix by removing or repointing the DNS record — that closes the hole immediately. Deleting the upstream resource without touching DNS does the opposite; it creates the dangle.
If the resource is one you still want, re-claim it yourself now (before an attacker does) and keep it provisioned.
Set the right teardown order going forward: repoint or delete the DNS record first, deprovision the cloud resource second. Never the reverse.

When to Escalate

If a subdomain is already serving content you didn’t publish, treat it as a live incident: pull the DNS record immediately, then check what that subdomain had access to — shared parent-domain cookies, OAuth redirect allowlists, CSP/CORS trust, and any internal tools that allowlisted it.
A dangling NS delegation is a full-zone takeover, not a single name. Escalate it above a normal cleanup ticket — the blast radius is every record an attacker could create under that subdomain.
If you can’t tell who owns a third-party CNAME target, that’s the real problem. Untracked vendor records are where takeovers live; get the subdomain into an inventory that someone reviews.