← Blog

Subdomain Takeover: Find Dangling DNS Records

2026-10-13 · 7 min read · By the DomainGuard team

The short version

Subdomain takeover happens when a DNS record points a subdomain at an external service, a cloud host, a CDN, a SaaS platform, that you've stopped using, and an attacker claims that service endpoint before you clean up the DNS. Your subdomain, e.g. partners.yourdomain.com, still resolves to the attacker's content. The browser shows your domain in the address bar. The attacker serves phishing pages, hosts malware, or harvests the cookies and credentials your users trust that domain with. It requires no phishing email and no malware on anyone's machine, just a DNS record everyone forgot. Finding these is a routine audit task; exploitation is fully scripted and widely automated.

How the takeover works, mechanically

The setup is almost always a dangling CNAME. Two years ago, marketing launched a campaign microsite on a cloud host: campaign.yourdomain.com → CNAME → campaign-acme.s3-website-us-east-1.amazonaws.com. The campaign ended, the bucket was deleted to save costs, but nobody removed the CNAME. The DNS record still exists, pointing at a cloud resource name that is now unclaimed.

The attacker enumerates your subdomains (more on how below), spots the CNAME pointing at a claimable resource, and re-registers that exact resource name on the cloud provider, creating a new bucket, app, or project with the same name. The provider happily serves the attacker's content at the resource address. Your DNS, unchanged, now routes your subdomain's visitors to the attacker's content. From the victim's perspective, everything checks out: the domain is yours, and if the attacker provisions a certificate for it (they control the content, so domain validation passes), the padlock is there too.

The same pattern applies across providers, expired Heroku apps, deleted Azure web apps, unclaimed GitHub Pages or Shopify or Zendesk hostnames, released CDN endpoints. The resource types differ; the shape is identical: your DNS points at someone else's claimable namespace.

A walkthrough: finding your own dangling records

This is a labeled hypothetical audit, the kind of pass every organization should run quarterly. The tooling is standard and open-source.

Step 1: enumerate your subdomains. Start with Certificate Transparency logs — every certificate ever issued for your domain is public, and each one names subdomains. A %.yourdomain.com search on crt.sh gives you the historical set. Add active enumeration with tools like subfinder or amass, which query certificate sources, search engines, and DNS datasets. Expect to be surprised; most companies find subdomains owned by teams that no longer exist.

Step 2: resolve everything and flag the externals. For each subdomain, check whether it's a CNAME pointing outside your infrastructure. Anything pointing at a cloud provider, CDN, or SaaS platform goes on the suspect list.

Step 3: test claimability. For each external CNAME, check whether the target resource still exists and whether it's still yours. The tells of a dangling record: the provider returns a "no such app/bucket/site" error page, a 404 from the platform's default error domain, or an NXDOMAIN-ish failure at the resource level while your CNAME itself still resolves. There are automated checkers for the common providers, but manual verification of each finding takes minutes and avoids false alarms.

Step 4: fix in the right order. If the resource is gone and unneeded: delete the DNS record first, then worry about the cloud side. If the resource is still needed: reclaim it under your own account immediately, then lock it down. Never leave a dangling CNAME "for later", later is when it gets claimed.

Why this keeps happening

Three structural reasons. First, DNS changes are made by different people than cloud-resource changes, often months apart, with no linking ticket between them. Marketing deletes the bucket; nobody tells whoever manages the zone file. Second, subdomains accumulate silently, every SaaS trial, every campaign, every contractor's demo adds records that outlive their purpose. Third, nothing alerts on it: a dangling CNAME doesn't break anything visible, doesn't page anyone, and doesn't show up in uptime monitoring. It just sits there, claimable, until someone claims it.

The fix is organizational more than technical: DNS changes and resource lifecycle need to be one process, not two. When a cloud resource is decommissioned, the corresponding DNS record dies in the same change ticket. When a SaaS trial ends, its verification records and CNAMEs get swept. Quarterly, someone runs the enumeration pass above and diffs it against the last one.

What attackers do with a taken-over subdomain

Control of a trusted subdomain is a versatile asset, and attackers use it in several ways:

• Credential phishing with home-field advantage. A login page on partners.yourdomain.com defeats every "check the domain" training you've ever given, because the domain is right. This is the highest-value use.
• Cookie and session theft. Scripts served from your subdomain can read cookies scoped to your domain, including session cookies for your main application, depending on how they're scoped. This turns a forgotten marketing subdomain into a session-hijacking platform.
• Malware and phishing-kit hosting. Your domain's reputation shields the payload from reputation-based filters that would flag a fresh malicious domain instantly.
• OAuth and redirect abuse. If your applications whitelist your own subdomains as OAuth redirect targets, a common configuration, the attacker can receive authorization codes and tokens.

Each of these is worse than the equivalent attack on an attacker-owned domain, because your domain's trust is doing the attacker's work for them.

The cleanup checklist

Run this quarterly, and after every decommissioning:

Enumerate, crt.sh wildcard search plus subfinder/amass, diffed against last quarter's list. New subdomains get an owner assigned; ownerless ones get investigated.

Classify — every external CNAME gets a verdict: active and owned (verify you control the target resource), active and someone else's problem (migrate or remove), or dangling (delete the DNS record now).

Reclaim or remove, for anything dangling, delete the DNS record first. For anything you still need on a third-party platform, confirm the resource is claimed under your account with no gaps.

Harden the process, tie DNS cleanup to resource decommissioning in the same ticket; require DNS-owner sign-off on cloud teardowns; add the enumeration diff to a recurring calendar item so it survives personnel changes.

Watch continuously, new dangling records appear between audits. Continuous subdomain and DNS monitoring catches the CNAME that goes dangling on a Tuesday, not the one you find in next quarter's spreadsheet.

FAQ

Can a subdomain takeover happen with A records, not just CNAMEs?

Yes, a subdomain pointing via A record at an IP address you released (a decommissioned VPS, an old load balancer) can be re-taken if the attacker gets that IP reassigned to them. Cloud IP space is recycled constantly, so released IPs are claimable in practice. CNAMEs to named resources are the more common case, but stale A records deserve the same audit.

Does HTTPS prevent subdomain takeover?

No. Once the attacker controls the content served at the resource, they can complete domain validation and obtain a valid certificate for your subdomain. HSTS and certificate pinning don't help either — the attacker serves from your domain legitimately as far as the browser can tell.

How do I check if a specific CNAME is dangling?

Resolve it and visit the target: provider "not found / no such app" error pages, or the platform's default unclaimed-resource page, are the classic tells. Confirm by checking whether the named resource exists in your own account on that platform. When in doubt, treat it as dangling and remove the DNS record, a record nobody can account for shouldn't exist.

Isn't this the cloud provider's problem to fix?

Providers have added mitigations (randomized resource names, claim verification), but the vulnerable configuration is yours: your DNS points at a namespace you don't control. No provider can distinguish "customer intends this delegation" from "customer forgot this delegation." The cleanup is the domain owner's job.