There's a DNS vulnerability that affects thousands of organisations right now, and most don't know about it. It's called a dangling DNS record — a CNAME or A record that points to a service you no longer use. An attacker can claim that service and take control of your subdomain.

This isn't theoretical. Subdomain takeovers have been exploited against major companies including Microsoft, Uber, and Starbucks. The fix is straightforward once you know what to look for.

What is a dangling DNS record?

A dangling DNS record is a DNS entry that points to a destination that no longer exists. The most common scenario involves CNAME records.

Here's how it happens:

You create blog.yourdomain.com and point it via CNAME to your-company.ghost.io
Months later, you move your blog to a different platform
You cancel your Ghost account, but forget to remove the CNAME record
The CNAME for blog.yourdomain.com still points to your-company.ghost.io, which no longer exists

Now an attacker can:

Create a new Ghost account using your-company as the subdomain
Ghost assigns them your-company.ghost.io
Your CNAME resolves to the attacker's content
Visitors to blog.yourdomain.com now see whatever the attacker wants

The attacker controls a subdomain on your domain — without ever touching your DNS or servers.

Why it matters

A hijacked subdomain isn't just embarrassing. It creates real security risks:

Phishing

Attackers can host convincing phishing pages on your subdomain. Since it's genuinely part of your domain, it bypasses many email filters and looks legitimate to victims.

Cookie theft

If your main site sets cookies on *.yourdomain.com (a wildcard cookie scope), the attacker's subdomain can read those cookies. This can include session tokens, authentication cookies, and CSRF tokens.

Reputation damage

Search engines may index the attacker's content under your domain. If they host malware or spam, your entire domain's SEO reputation suffers.

Email spoofing

With control of a subdomain, attackers may be able to send emails that pass SPF checks for your domain, depending on your SPF configuration.

Which services are vulnerable?

Subdomain takeover is possible when a cloud service allows users to claim custom subdomains and the service returns a recognisable error page when the subdomain isn't claimed. Common vulnerable services include:

GitHub Pages — returns a 404 page when the repository is deleted
Heroku — returns "No such app" when the app is removed
AWS S3 — returns "NoSuchBucket" when the bucket is deleted
Azure — various services return identifiable error pages
Shopify — shows a Shopify landing page when the store is closed
Ghost — shows a default page when the site doesn't exist
Fastly, Cloudfront, Surge.sh — similar patterns

Each service has different indicators. An attacker typically scans for these error pages across large numbers of domains to find targets.

How to find dangling records

Manual audit

Review all your DNS records and check whether each CNAME, A record, and NS delegation still resolves to an active service. This works for small setups but gets tedious quickly.

Automated scanning

Use ScanMyDomain to scan your domain. It automatically checks for dangling CNAME records by resolving the target and verifying it responds. If a CNAME points to a dead endpoint, it flags it as a subdomain takeover risk.

Check for common indicators

Visit each subdomain in your browser. If you see any of these, you likely have a dangling record:

"There isn't a GitHub Pages site here"
"No such app" (Heroku)
"NoSuchBucket" (AWS S3)
"Domain not found" or a generic hosting provider page
Connection timeouts on CNAME targets

How to fix dangling records

The fix is simple: delete the DNS record.

If you're no longer using a service, remove the CNAME, A record, or NS record that points to it. There's no reason to keep DNS records for services you've decommissioned.

Step-by-step cleanup

Export your DNS zone — download all records from your DNS provider
List all CNAME records — these are the highest risk
Verify each target — does the CNAME destination still respond with your content?
Delete dead records — remove any record pointing to a service you no longer use
Check A records too — IP addresses pointing to decommissioned servers are also a risk
Review NS delegations — if you delegated a subdomain to a third-party DNS and cancelled that service, remove the NS records

What about records you're unsure about?

If you're not sure whether a CNAME is still in use, check:

Does the target hostname resolve? (dig CNAME subdomain.yourdomain.com)
Does it return your content when accessed via browser?
Is there an active account or subscription associated with the service?

When in doubt, remove the record. If something breaks, you'll know it was still in use and can re-add it.

Prevention

Maintain a DNS inventory

Keep a document or spreadsheet listing every DNS record, what service it points to, who set it up, and when. Review it quarterly.

Delete records when decommissioning services

Make DNS cleanup part of your offboarding process for any cloud service. When you cancel a Heroku app, delete the CNAME. When you shut down a staging environment, remove the A record. Build it into your runbook.

Use monitoring

Set up automated scanning to catch dangling records before attackers do. ScanMyDomain checks for this as part of every scan, so enabling weekly monitoring on your domain gives you ongoing protection.

Limit wildcard DNS

Avoid wildcard DNS records (*.yourdomain.com) unless absolutely necessary. Wildcards mean every possible subdomain resolves, massively increasing your attack surface.

Restrict subdomain cookie scope

Don't set cookies on *.yourdomain.com unless required. Use specific subdomain scoping to limit the blast radius if a subdomain is compromised.

Real-world examples

Subdomain takeovers have affected organisations of all sizes:

Researchers have found vulnerable subdomains on domains belonging to major tech companies, government agencies, and financial institutions
Bug bounty programs regularly pay out for subdomain takeover reports
Automated scanners continuously crawl the internet looking for dangling records

The common thread is that these organisations had strong security practices for their main domain but overlooked orphaned DNS records for old services.

Summary

Dangling DNS records are a hidden risk that's easy to overlook and easy to fix. Audit your DNS records, delete anything pointing to decommissioned services, and set up monitoring to catch new issues. Scan your domain now to check for dangling CNAME records and other DNS health issues.

Dangling DNS Records: The Subdomain Takeover Risk You're Probably Ignoring