What is a dangling DNS record?

A dangling DNS record is one that points at a destination that no longer exists or that you no longer control: a CNAME to a cancelled SaaS hostname, an A record to a cloud IP address you released, an NS delegation to name servers that no longer host the zone, or an alias to a deleted storage bucket or app. The record itself is harmless until someone else obtains the destination — at which point your hostname resolves to their infrastructure, which is the subdomain-takeover condition. Dangling records accumulate because deleting DNS entries is nobody's job when a service is cancelled. They are found by enumerating your subdomains and checking, for each CNAME, whether the target still resolves.

How do I check if my subdomain can be taken over?

First find the dangling candidates: enumerate your subdomains from Certificate Transparency and your DNS zone, and for every CNAME check whether the target resolves — a target that returns NXDOMAIN is the signature. Our Subdomain Finder does this passively and labels such hosts 'Dangling'. Second, determine whether the target's provider lets anyone claim the released name: fetch your own hostname and look for the provider's 'unclaimed' page ('no such app', 'there isn't a GitHub Pages site here', 'bucket does not exist'), and consult the community can-i-take-over-xyz list for that provider's status. If either signal is present, treat it as exploitable and remove or re-point the record now; if not, remove it anyway — there is no reason to keep a record pointing nowhere.

Is a subdomain takeover a serious vulnerability?

It is usually rated high in bug-bounty programs, and for good reason: the attacker gets a page on a genuine hostname of yours, served over HTTPS, which defeats the URL-checking advice users are given and makes phishing far more convincing. Depending on how your cookies and email are configured it can also expose session cookies scoped to the parent domain and allow mail to be sent or received under the subdomain. The severity in any specific case depends on whether the provider actually allows claiming the released name and on your cookie and email scoping, which is why a passive check reports the dangling record as a low-severity 'verify this' item rather than a confirmed hole. The remediation is trivial either way — delete or re-point the record.

Subdomain Takeover — Dangling CNAME and DNS Records Explained

A subdomain takeover happens when one of your DNS records still points at a service you no longer use — a CNAME to a cancelled SaaS, a cloud storage bucket, a deleted app — and someone else claims that service name. Your hostname then serves their content, with your brand and often your cookies. The cause is always the same: a dangling DNS record. The fix is one DNS change.

How does a subdomain takeover happen?

Three steps, none of them clever:

You set help.example.com CNAME acme.helpdesk-saas.com (or blog. to a blog platform, assets. to a storage bucket, app. to a cloud app hostname).
You cancel the service. The provider releases acme. Your DNS record stays — nobody's job was to delete it.
Anyone signs up for the same provider and claims acme. Their content now answers at help.example.com, over HTTPS if the provider issues certificates automatically.

Whether step 3 is possible depends on the provider: some verify domain ownership before serving a custom hostname, many historically did not. The community-maintained can-i-take-over-xyz list tracks which services are claimable. The same mechanism applies to NS delegations to a decommissioned DNS zone and to A records pointing at released cloud IPs, though CNAMEs are by far the most common.

Why does it matter if the page is just someone else's content?

Phishing with a real hostname — a login page at help.example.com passes every “check the URL” lesson your users ever learned.
Cookies — if your session cookies are scoped to .example.com, the attacker's subdomain receives them; see cookie scope.
Email — a taken-over subdomain can be used to send mail that passes SPF for that subdomain if the record set allows it, and to receive password resets addressed to it.
Reputation and search — spam or malware served under your domain gets your domain blacklisted and de-ranked.

How do you check for dangling DNS records?

Enumerate your subdomains, then look for CNAMEs whose target does not resolve. The Subdomain Finder does exactly this passively and labels the result Dangling; it reports it as LOW with “verify” wording because DNS can show the pre-condition but cannot tell whether the provider will let someone claim the name.

# A CNAME whose target returns NXDOMAIN is the signature
dig +short CNAME promo.example.com        # → pages.oldtool.io.
dig +short A pages.oldtool.io             # → (nothing)  ← dangling

# Provider-specific "unclaimed" pages are the second signal (fetch only your OWN hostnames)
curl -sI https://promo.example.com | head -1
curl -s  https://promo.example.com | grep -iE "no such app|there isn't a github pages site|bucket does not exist|unknown domain"

Do the same for NS records delegating a subdomain to name servers that no longer answer for it, and for A/AAAA records pointing into cloud ranges where you no longer hold the address.

Common gotcha: the record that bites you is rarely on the main zone you look at every week. It is the client's domain from three agencies ago, the subsidiary's zone, or the vanity domain registered for one campaign. Enumerate every domain you own, not just the primary one — and put “delete the DNS record” on the checklist of every service you cancel.

For the site owner and for the developer

For the site owner (plain English)

A subdomain takeover means a stranger can put their own page on a web address that belongs to your company, because a leftover DNS setting still points at a service you stopped using. Ask whoever manages your DNS to run a check for “dangling” records and delete them; it takes minutes. Then make a rule: cancelling any web service includes removing its DNS record.

Run your domain through the Subdomain Finder — dangling CNAMEs are flagged with the target that no longer resolves, ready to hand to whoever manages DNS.

Check for dangling records →

For the developer / IT (fix and prevent)

Fix: delete the record, or re-point it to a resource you control. If the hostname must keep existing (links in the wild), point it at your main site with a redirect rather than leaving it dangling.
Reclaim first if already taken: claim the target at the provider yourself where possible, then remove the record; report abuse to the provider if content is live.
Prevent — process: DNS changes go through the same review as code; every SaaS cancellation ticket has a “DNS record removed” checkbox.
Prevent — technical: prefer providers that verify domain ownership (TXT challenge) before serving a custom hostname; scope session cookies to the exact host, not the apex; keep frame-ancestors and CSP tight so a hostile subdomain can't frame or script the main site.
Detect continuously: re-run the passive check monthly and diff; the monitoring guide shows how to alert on new dangling targets and new certificates issued for your names.

# Monthly: list dangling CNAMEs across all your zones
for h in $(cat all-hosts.txt); do
  t=$(dig +short CNAME "$h" | head -1)
  [ -n "$t" ] && [ -z "$(dig +short A "$t")$(dig +short AAAA "$t")" ] && echo "DANGLING $h -> $t"
done

Subdomain Takeover: How Dangling DNS Records Hand Your Hostname to a Stranger