Subdomain Takeover: How Dangling DNS Gets Hijacked

A subdomain takeover happens when one of your subdomains still points at a cloud service you stopped using, and someone else claims that service. From then on, they control what loads at shop.example.com or docs.example.com: a phishing page, malware, or a script that reads cookies scoped to your domain. Nothing on your main website changed, which is why subdomain takeover often goes unnoticed for months.

How a Subdomain Takeover Works

Most subdomain takeover cases follow the same four steps:

1. A team creates a resource on a hosting service, for example a storage bucket, a static site or a help desk portal, and adds a DNS record: help.example.com CNAME example.helpdesk-provider.com.
2. Later the resource is deleted, the trial ends or the project is abandoned. The DNS record stays.
3. The CNAME now points at a name the provider no longer assigns to you. This is called a dangling CNAME or dangling DNS record.
4. An attacker signs up to the same provider, creates a resource with the same name, and the provider starts serving their content for help.example.com.

$ dig +short help.example.com CNAME
example.helpdesk-provider.com.
$ curl -s https://help.example.com | head -1
<h1>There is no portal here. Claim this name?</h1>

The provider's "not found" or "claim this name" page is often the fingerprint that shows a subdomain takeover is possible.

Why Subdomain Takeover Is Dangerous

• Convincing phishing. A login page at login.example.com looks real because it is on your real domain, with a valid certificate the attacker can get automatically.
• Cookie theft. Cookies set for .example.com are sent to every subdomain. A taken-over subdomain can read them. See secure cookie configuration for why the cookie Domain attribute matters.
• Bypassing security policies. A Content Security Policy or CORS rule that trusts *.example.com now trusts the attacker. The CSP guide and CORS guide explain why wildcards are risky.
• Reputation and SEO damage. Spam or malware on your domain can get it flagged by browsers and search engines.

Which Services Are Affected

Any service that lets a customer claim a hostname, and does not verify that they own the domain pointing at it, can allow a subdomain takeover. Commonly reported examples include some static hosting and storage services, help desk and documentation platforms, landing page builders and older platform-as-a-service offerings. Providers change their behavior over time, and many now require domain verification. The community project can-i-take-over-xyz keeps a list of which services are vulnerable and what their "unclaimed" page looks like.

Subdomain takeover does not only come from CNAME records. An A record pointing at a cloud IP address you released can also be claimed when the provider gives that IP to another customer, and NS records delegated to a deleted DNS zone are even more dangerous, because the attacker controls every record below them.

How to Find Dangling DNS Records

1. List your subdomains. Export every record from your DNS provider. Certificate Transparency logs also list every subdomain that ever had a public certificate, which helps find old ones nobody remembers.
2. Resolve each CNAME. Check where it points, and whether that target still exists or returns NXDOMAIN.
3. Request each subdomain over HTTP. Look for a provider's "no such app", "bucket does not exist" or "domain not configured" page.
4. Repeat regularly. New dangling records appear every time a project is shut down.

A security scan runs a subdomain takeover check for you. It discovers subdomains from Certificate Transparency logs, checks up to 60 of them, resolves each CNAME against fingerprints of around 50 hosting and SaaS providers from the can-i-take-over-xyz list, and requests the subdomain to look for the provider's unclaimed page. It lists every subdomain it checked, not just the ones it flags. It is a passive check: it does not try to claim anything. It only covers subdomains that appear in certificate logs, so check your DNS export too for internal names that never had a public certificate.

How to Fix a Subdomain Takeover Risk

• Delete the DNS record for any subdomain that points at a resource you no longer use. This is the fix in almost every case.
• Change the order of shutdown. When you retire a service, remove the DNS record first and delete the cloud resource second. Doing it the other way around opens a window for subdomain takeover.
• If a subdomain is already taken over, delete or repoint the DNS record immediately, then check logs for what was served, rotate any cookies or sessions that could have been exposed, and report the account to the provider.
• Use domain verification features where the provider offers them, such as TXT record ownership checks.
• Keep an inventory. Record who owns each subdomain and what it points at, so retired projects are cleaned up.
• Avoid wildcard trust. Do not trust *.example.com in CSP, CORS or cookie scope unless every subdomain is under your control.

Subdomain Takeover in the OWASP Top 10

Subdomain takeover is a security misconfiguration, the kind of issue covered in the OWASP Top 10 for website owners. It needs no exploit code and no access to your servers, which is what makes it common in bug bounty reports. The fix is mostly process: clean up DNS when you shut things down, and scan your subdomains on a schedule. To understand how scan findings are graded and what to fix first, see how to read a security scan report.