What are dead and dangling subdomains?
Over time, organisations accumulate DNS records that no longer point to anything useful. Since servers cost money and domain records does not, it's very common that the server is removed but the DNS record lives on. Two categories appear in ExposureIndex findings:
Dead subdomains are DNS records that point to an IP address or hostname that no longer exists or no longer serves content for you. The record is technically alive in DNS but the destination is gone.
Dangling subdomains (also called subdomain takeovers) are a more serious subset: DNS records that point to a third-party service (e.g. a Heroku app, GitHub Pages, AWS S3 bucket, Azure endpoint, or similar) that has been decommissioned on that service but where the DNS record was never removed. An attacker can register the same resource on the third-party platform and gain control of your subdomain — with a valid HTTPS certificate.
Why subdomain takeover is serious
When an attacker takes over a dangling subdomain they effectively own dangling.yourdomain.com. From that position they can:
- Serve phishing pages under your trusted brand name
- Steal cookies scoped to
*.yourdomain.comif your cookie policy is too broad - Send email from the subdomain, potentially bypassing spam filters
- Host malware or drive-by downloads that appear to originate from your domain
The attack requires no compromise of your infrastructure — just a DNS record pointing somewhere the attacker can claim.
What to do
Step 1 — Audit your DNS records
What ExposureIndex do is to enumerate as many subdomains as possible that are regisred under your domain. We could however miss some. So the most effective way of having control is to export all DNS records for your domain.
For each CNAME, A, and AAAA record, verify:
- Does the destination still exist?
- Is the destination still under your control?
Pay special attention to CNAMEs pointing to:
- *.herokudns.com, *.herokuapp.com
- *.azurewebsites.net, *.cloudapp.net
- *.github.io
- *.s3.amazonaws.com, *.s3-website-*.amazonaws.com
- *.netlify.app, *.vercel.app
- *.zendesk.com, *.shopify.com, *.ghost.io
These are common sources of dangling subdomains because projects on these platforms are frequently created and deleted without corresponding DNS cleanup.
Step 2 — Remove records you no longer need
For every subdomain that is dead or dangling, delete the DNS record. This is the only reliable fix. There is no benefit to keeping DNS records for services you no longer use.
Step 3 — Claim the resource (temporary stopgap)
If immediate DNS removal is not possible (e.g. a deployment is in progress), re-claim the resource on the third-party platform under your account to prevent an attacker from claiming it first. This is a stopgap only — remove the DNS record as soon as the deployment is complete.
Step 4 — Establish a decommission checklist
The root cause of dangling subdomains is always the same: a service was turned off but the DNS record was not cleaned up. Add "remove DNS record" as a mandatory step in your service decommission runbook.
Identifying takeover-vulnerable CNAMEs
You can check a CNAME's destination for common "unclaimed" error messages. For example:
- Heroku:
No such apporThere's nothing here, yet - GitHub Pages:
There isn't a GitHub Pages site here - AWS S3:
NoSuchBucket - Azure:
The requested resource is not found
If your subdomain's CNAME resolves to one of these, it is likely vulnerable to takeover.
Last updated: March 28, 2026