Subdomain Takeover (Dangling DNS)
Also known as: Subdomain squatting, Dangling CNAME takeover, Dangling DNS record
A condition where a DNS record still points at a cloud resource that has been deleted, letting a third party register that resource and serve content under your trusted subdomain.
How it works
A subdomain takeover is possible when a DNS record such as a CNAME or ALIAS still points to a cloud resource, for example a storage bucket, an app-platform site, a CDN endpoint or a SaaS tenant, that has since been deleted. The name still resolves into the provider, but nobody owns what it points to.
Many providers let any customer register a resource name that is currently free. If your record still points at that name, whoever registers it now controls what is served on your subdomain. Visitors see a hostname they trust, and it can carry your cookies, pass your domain checks and appear in your own links.
The impact is usually reputational and credential-related: phishing pages on a legitimate domain, session cookies scoped to the parent domain being exposed, and email or OAuth trust being abused. Nothing in your own servers was breached; the weak point was a forgotten record.
Defence is about hygiene and visibility. Remove the DNS record before or together with the resource, keep an inventory that ties every record to an owner and a live backend, scan continuously for records whose targets no longer resolve or return a provider's unclaimed-resource page, and use provider ownership-verification features where they exist.
Walk through it
- 1Spot the dangling record
- 2Read the zone and the risk
- 3Choose the fix
- Scope exposure and cookies
- Automate monitoring and decommissioning
Your weekly DNS inventory check has just finished. Most records point at live backends, but one CNAME points to a target that no longer exists. Type the hostname you would escalate.
Records for tailwind.example
www.tailwind.example CNAME shop-edge.cdn.example backend=200 OK
api.tailwind.example CNAME api-lb.tailwind.example backend=200 OK
assets.tailwind.example CNAME tailwind-assets.s3.example backend=200 OK
promo2024.tailwind.example CNAME tw-promo.apps.example backend=NXDOMAIN (target does not exist)
status.tailwind.example CNAME tw-status.statuspage.example backend=200 OK
Spot it
- A CNAME or ALIAS whose target returns NXDOMAIN.
- A record whose backend returns a provider's 'no such bucket', 'no such app' or 'domain not configured' page.
- Inventory records with no owner, no ticket reference or no review date.
- Content, certificates or favicons on a subdomain that do not match your hosting or brand.
- Certificate transparency entries for one of your subdomains issued to an unknown party.
DNS inventory scanner
ts=2026-10-11T06:00:02Z host=promo2024.tailwind.example type=CNAME target=tw-promo.apps.example resolves=false status=NXDOMAIN owner=none
ts=2026-10-11T06:00:03Z host=www.tailwind.example type=CNAME target=shop-edge.cdn.example resolves=true status=200 owner=web-teamCertificate transparency monitor
ts=2026-10-11T07:15:40Z name=promo2024.tailwind.example issuer=public-ca event=new-cert alert=not-issued-by-uskqlKQL, inventory records whose backend does not resolve
DnsInventory
| where Domain endswith "tailwind.example" and RecordType in ("CNAME", "ALIAS")
| where TargetResolves == false or BackendStatus in ("NXDOMAIN", "UnclaimedResource")
| project Host, Target, BackendStatus, Owner, LastReviewedTreat any hit as high severity until the record is removed or the backend is confirmed to be yours.
splSplunk, records with no owner or stale review
index=dns sourcetype=inventory record_type IN (CNAME, ALIAS)
| where isnull(owner) OR owner="none" OR last_review < relative_time(now(), "-90d")
| table host target backend_status owner last_reviewStop it
Remove DNS when you remove the resource
Make deleting the DNS record part of decommissioning, ideally before the backend is deleted. A record that points nowhere cannot be claimed by anyone else.
Inventory every record with an owner and a live backend
Keep an authoritative list of records tied to an owner and a purpose, and scan continuously for targets that no longer resolve or that return an unclaimed-resource page.
Verify ownership and constrain the blast radius
Use provider domain-ownership verification where available, avoid wildcard records that point to third parties, scope cookies to the narrowest host, and monitor certificate transparency for your names.
Find and remove a dangling record
Vulnerable
promo2024 300 IN CNAME tw-promo.apps.example. ; backend deletedHardened
# 1. confirm the backend is gone
dig +short CNAME promo2024.tailwind.example
dig +short tw-promo.apps.example # empty / NXDOMAIN
# 2. remove the record via change control
# (delete the promo2024 CNAME from the zone, then verify)
dig +short promo2024.tailwind.example # expect no answerUse your DNS provider's change process. The key step is removal after confirming no legitimate use remains.
- Add a DNS cleanup step to every decommissioning runbook, owned by the same team that deletes the resource.
- Require owner and purpose fields on every DNS record, with a periodic review date.
- Scan all records daily for NXDOMAIN targets and provider unclaimed-resource pages.
- Use provider ownership-verification (TXT or similar) wherever the service supports it.
- Avoid wildcard CNAMEs to third-party services and scope cookies to specific hosts.
- Monitor certificate transparency logs for certificates issued for your subdomains.
If it already happened
Remove the dangling record immediately, or reclaim the backend resource under your own account if the name must stay live. Revoke any certificate issued to an unknown party for the name.
Review sibling records for the same pattern, rotate any cookies or tokens that were scoped to the parent domain and could have been exposed, and check links or email that referenced the name.
Confirm the name no longer resolves into the provider, the scanner reports zero dangling records, and users see no unexpected content.
Add the DNS cleanup step to the decommissioning runbook, make owner fields mandatory and schedule the scanner as a recurring detection with alerting.
Check yourself
1. What condition makes a subdomain takeover possible?
2. Which scan result is the strongest sign of a dangling record?
3. What is the best way to prevent subdomain takeovers over time?