Subdomain takeover: find dangling DNS records before someone else does

What you'll learn

• How a forgotten DNS record turns into someone else's website on your domain
• Which record types are at risk, beyond the classic dangling CNAME
• A short script that checks every CNAME in a zone file
• How DNS traffic shows forgotten names and subdomain enumeration
• The decommissioning order that prevents takeovers

Someone sets up promo.example.com as a CNAME to a landing page on a hosting platform. The campaign ends, the app is deleted, the DNS record stays. Months later another customer of the same platform creates an app with the freed name, and promo.example.com now serves their page: phishing, malware, or just an embarrassing screenshot, on your domain, behind HTTPS.

1 How a takeover happens

Many cloud services let you attach a custom domain by pointing a CNAME at a name they assign, such as an app, bucket or site name. The service decides which customer owns that name. When you delete the resource, the name returns to the pool, but your DNS keeps sending visitors to it.

1. Your record promo.example.com CNAME promo-site.platform.example stays in the zone.
2. The resource is deleted, so promo-site.platform.example stops existing or shows a "no such site" page.
3. An attacker registers promo-site at the same platform and attaches your hostname.
4. The platform issues a certificate for promo.example.com, because DNS already points there.

The damage goes beyond one page. A browser treats the subdomain as yours: cookies scoped to .example.com can be read there, policies that trust *.example.com trust it too, and users have no way to tell the difference.

2 Which records are at risk

Record	Risky when it points at	What the attacker does
CNAME	A deleted app, bucket, CDN endpoint or SaaS custom-domain target	Claims the same name at the provider
CNAME, MX	A domain whose registration has expired	Registers the domain and controls the target
NS (delegated subdomain)	A hosted zone that was deleted at a DNS provider	Creates the same zone at that provider and answers for your subdomain
A, AAAA	A cloud IP address you released	Gets the address assigned and serves content on it

3 Find dangling records yourself

3.1 Check every CNAME in the zone

Export the zone in BIND format (most providers offer this) and resolve each CNAME target. NXDOMAIN means the target no longer exists: the record is broken at best and claimable at worst.

awk '{for (i = 1; i < NF; i++) if ($i == "CNAME") print $1, $(i+1)}' example.com.zone |
while read -r name target; do
  status=$(dig +noall +comments "$target" A | grep -o 'status: [A-Z]*')
  echo "$name -> $target  $status"
done

Treat anything other than NOERROR as a lead. SERVFAIL often means a broken delegation further down the chain.

3.2 A target that resolves can still be claimable

Many platforms keep resolving the assigned name after the resource is gone and show their own error page instead. Fetch each hostname and look at what comes back:

curl -s -o /dev/null -w "%{http_code}\n" https://promo.example.com
curl -s https://promo.example.com | head -20

A 404 with the platform's branding ("no such app", "bucket does not exist", "site not found") on a name you thought was retired needs action. The community-maintained can-i-take-over-xyz list documents which services can be claimed this way and what their error pages look like.

3.3 Check delegated subdomains

If dev.example.com is delegated to another DNS provider, ask its nameservers for the zone. A refusal means the zone no longer exists there:

dig +short NS dev.example.com
dig dev.example.com SOA @ns-123.provider.example   # REFUSED or SERVFAIL: the delegation is dangling

3.4 Do not forget names you no longer list

Certificate transparency logs record every hostname a public certificate was issued for, and attackers use them to find subdomains. Use them the same way, to find names that exist somewhere but not in your inventory:

curl -s "https://crt.sh/?q=%25.example.com&output=json" | grep -o '"name_value":"[^"]*"' | sort -u

4 Watch what DNS traffic tells you

Your authoritative DNS sees two useful signals:

• Names that keep being asked for after you removed them. Steady NXDOMAIN traffic for a deleted name means links, clients or integrations still use it. Find out what before someone else gives it an answer.
• Bursts of NXDOMAIN for many different names from one source in a short time. That is subdomain enumeration: someone guessing dev, staging, vpn, old to map what you have.

5 Prevent it: the decommissioning order

1. Remove or change the DNS record first, then delete the cloud resource. Never the other way round.
2. Turn on domain verification where the provider offers it. Many platforms can require a TXT record proving you own the domain before anyone can attach it.
3. Know who owns each record. A record nobody can explain is a record nobody will remove. An audit log that shows who created it is often the fastest way to find the owner.
4. Avoid wildcard CNAMEs to third-party platforms; one forgotten wildcard covers every name.
5. Review the zone regularly with the checks above, for example every quarter and after every migration.

6 How PrimeDNS helps

• Top NXDOMAIN names in PrimeDNS Observability show which names people still ask for after they were removed.
• NXDOMAIN bursts flag the pattern of subdomain enumeration against your zones, with the time and the zone affected.
• Dangling CNAME alerts point out CNAME records whose target is a name in your PrimeDNS zones that no longer exists.
• Zone export in BIND format, in the panel and through the API, so the script above runs on an up-to-date copy.
• The Audit Log shows who created each record and when, which answers "whose is this?" before you delete it, and per-zone roles keep people from adding records to zones they do not look after.

See the Observability guide and the Audit Log guide.

7 Frequently asked questions

What is a dangling CNAME?

A CNAME record whose target no longer exists, or no longer belongs to you. It is broken for users and, on many cloud platforms, can be claimed by someone else.

Does HTTPS protect against subdomain takeover?

No. Once the attacker controls the target, the platform or any certificate authority will issue a valid certificate for your hostname, because your DNS points there.

Does DNSSEC prevent subdomain takeover?

No. DNSSEC proves that the answer came from your zone unchanged. A takeover uses an answer that really is in your zone, so DNSSEC signs it like any other.

How do I fix a subdomain that was taken over?

Delete or change the DNS record immediately, then contact the platform to remove the resource and review logs for what was served and to whom. Check for other records pointing at the same platform.

8 References

1. can-i-take-over-xyz: community list of services and takeover fingerprints
2. OWASP Web Security Testing Guide (Test for Subdomain Takeover)
3. crt.sh: certificate transparency log search
4. RFC 6962: Certificate Transparency