Subdomain takeover explained: dangling DNS and how to fix it
Subdomain takeover happens when DNS points at a cloud resource you no longer control. Learn the dangling-CNAME mechanism, the impact, and how to find and fix it.
A subdomain takeover happens when a DNS record on your domain points at an external resource — a storage bucket, a PaaS app, a CDN distribution — that has been deprovisioned, and someone else claims that resource. The DNS record still resolves, the hostname still belongs to you, but the content behind it now belongs to an attacker. No credentials were stolen and no server was breached: the attacker simply registered something you had forgotten you were pointing at.
It is one of the most common findings in external attack-surface assessments, because the conditions that create it are routine. A marketing campaign ends, a proof of concept gets torn down, a vendor contract lapses. The infrastructure disappears. The CNAME does not.
How subdomain takeover works
The mechanics are simple and worth understanding precisely, because the fix follows directly from them.
The fix: remove the CNAME the moment you decommission the service it points at — or monitor continuously so a newly-dangling record is flagged before an attacker finds it.
- You delegate a subdomain to a third-party service. Typically a CNAME —
shop.example.com→something.cloud-provider.example— but it can also be an A record pointing at a since-released IP, or NS records delegating a zone to nameservers that no longer answer for it. - The resource behind the record is deprovisioned. The app is deleted, the bucket removed, the trial expires. Crucially, nobody removes the DNS record.
- The provider lets a new customer claim the same identifier. Many multi-tenant platforms route traffic by hostname: whoever registers the name (or adds your custom domain to their account) receives requests for it. An attacker registers the abandoned identifier, and your subdomain now serves their content.
The vulnerable window can be minutes or years. Attackers do not search blindly —
abandoned resources advertise themselves through distinctive error pages ("this app
doesn't exist", "bucket not found") and through NXDOMAIN responses on CNAME targets,
both of which are trivially detectable at scale.
Why it matters more than "someone defaced a page"
A takeover is often dismissed as a content-spoofing issue. It is considerably worse, because the attacker's content is served from your origin.
| Consequence | Why it works |
|---|---|
| Cookie theft and session abuse | Cookies scoped to .example.com are sent to every subdomain — including the hijacked one |
| Convincing phishing | The URL is genuinely yours; users and email filters have little reason to distrust it |
| CSP and CORS bypass | Policies that whitelist *.example.com now whitelist attacker-controlled content |
| OAuth redirect abuse | Allow-lists that match on your domain may accept the hijacked host as a valid redirect target |
| Valid TLS | The attacker can often obtain a certificate for the hostname, since they control what it serves |
If your security model assumes "anything on our domain is ours", a single dangling CNAME quietly breaks every one of those assumptions.
The common vulnerable service classes
The specific providers change, but the classes do not:
- Unclaimed storage buckets. A CNAME points at a bucket-style endpoint where the bucket name is derived from your hostname. Delete the bucket and anyone can recreate it.
- Deprovisioned PaaS apps. Platform-as-a-service hosts route by app name or by registered custom domain. Once the app is gone, the name returns to the pool.
- CDN distributions. A CNAME to a distribution endpoint whose custom-domain mapping has been removed can sometimes be re-mapped by another account.
- Third-party SaaS custom domains. Help desks, status pages, landing-page builders — anything offering "use your own domain" with weak proof of ownership.
- Lapsed NS delegations. A delegated child zone whose nameserver provider account has closed; an attacker who re-registers the zone at that provider controls everything under it.
Some providers have since added domain-verification requirements that close the loop. Many have not, and your DNS zone almost certainly references both kinds.
How to detect dangling records in your own zones
Detection is a DNS-auditing exercise. For each subdomain you publish, ask: does the thing this record points at still exist, and do we still control it?
A CNAME whose target no longer resolves is the loudest signal:
$ dig +short shop.example.com CNAME
old-campaign-site.examplecdn.net.
$ dig shop.example.com A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41170
That NXDOMAIN on a target you are still CNAMEd to is exactly what attackers scan for.
But absence of NXDOMAIN does not mean safe — many platforms resolve fine and return a
"resource not found" page, which is just as claimable. A thorough audit therefore
combines:
- Full enumeration of your subdomains — zone exports where you control DNS, certificate transparency logs and passive DNS where you do not. You cannot audit records you do not know exist.
- Resolution checks on every CNAME, A/AAAA and NS record, flagging
NXDOMAINtargets, released IP ranges and dead delegations. - Fingerprinting of responses against the known error signatures of claimable services.
- Repetition. This is the part teams miss: a zone that was clean in January grows a dangling record the day a project is decommissioned in March. One-off audits decay immediately.
Remediation and prevention
When you find a dangling record you have two clean options: delete the DNS record (correct when the service is genuinely retired) or reclaim the resource so the record points at something you control again. Deleting is almost always the right call — a record with no purpose is pure liability.
To stop the pattern recurring:
- Make DNS cleanup an explicit step in decommissioning runbooks: the record is removed before the resource is destroyed, never after.
- Treat DNS changes as code — reviewed, versioned, and owned — so every record has an accountable owner and a removal path.
- Prefer providers that verify domain ownership before serving a custom hostname, and note the ones that do not.
- Monitor continuously, because process catches the planned teardowns and monitoring catches everything else.
Subdomain takeover persists not because it is clever but because DNS zones outlive the infrastructure they describe. The defence is unglamorous: know every record you publish, verify each one still points at something you control, and keep checking.
DomainOps runs continuous subdomain enumeration and takeover-risk detection across your own domains and alerts you when a record starts dangling — see how it works in the exposure-monitoring docs. You can also run a quick one-off check with our free subdomain takeover scanner. When you are ready to watch a whole estate continuously, get started in a few minutes.