Dangling DNS record — Domainee Glossary

A DNS record pointing at a target that's no longer under your control. The exact precondition for subdomain takeover.

A dangling DNS record is one that resolves to a target you no longer control. The classic case: a CNAME from marketing.example.com to mybrand.unbouncepages.com. You stop paying Unbounce. Unbounce deprovisions your account but the DNS record stays. Anyone can claim the mybrand.unbouncepages.com subdomain on Unbounce and serve content at marketing.example.com.

The result is subdomain takeover: your domain reputation, your TLS auto-issuance, your cookies all start serving an attacker's content.

Common causes

Decommissioned SaaS apps. You used to use Heroku, GitHub Pages, AWS S3, Shopify, Webflow, Fastly. You stopped. DNS records pointing at those services still exist.
Test or staging subdomains. staging-old.example.com CNAME old-staging.elb.amazonaws.com. The ELB was deleted years ago. The CNAME wasn't.
One-off projects. Engineer A spun up a quick demo in October 2023 at demo.example.com. They left the company in March 2024. DNS still points at their old demo-co-abc.herokuapp.com that they never paid the renewal on.
Migration leftovers. You moved from one CDN to another. The CNAME at the old CDN is dead but not deleted.

How attackers find them

Bug bounty hunters and pentesters use tools like:

subjack — checks subdomains against a list of takeover-prone services and tells you which ones are dangling.
subzy — similar, with broader service signatures.
dnsx + httpx + nuclei — scan a domain's full subdomain set, find HTTP failures, check for takeover signatures.

You can run the same tools defensively. Run subjack against your own domain monthly. Investigate every hit.

How to clean up

Audit:

List all DNS records for your domain. Tools: your DNS provider's export, dig axfr if you can, crt.sh for hostnames that appeared in cert logs.
For each CNAME, A, ALIAS: does the target resolve? Does it return the expected content? If 404 or NXDOMAIN, it's dangling.
For each apparently-orphaned record: was the service truly decommissioned? Could it be reactivated? If decom: delete the record.

Prevention going forward

Lifecycle every external-resource subdomain. When you deprovision a SaaS app, the deprovisioning ticket should include "remove DNS records pointing at it."
Monitor your domain with a continuous subdomain takeover scanner. Free tools: Detectify-style internal scripts, the Bishop Fox domain monitor. Paid: dnsdumpster, SecurityTrails, Detectify, Censys.
Limit who can create DNS records to a known list of teams or systems. Document who's responsible for each.

In a custom-domain SaaS

This is your customers' problem, not yours, but it affects you. If a customer creates a vanity CNAME at app.theirbrand.com pointing at your edge, then cancels their account but leaves the DNS record, the next person to register app.theirbrand.com on your platform might end up controlling content under their brand. Defense: keep custom hostnames "claimed" in your platform's DB even after subscription cancellation, until the customer removes the DNS record on their end. Don't release claimed hostnames automatically.