If you run a website, manage infrastructure, or work in DevOps — there's a good chance you have at least one forgotten subdomain pointing at a service you no longer use.
It's not negligence. It's just how the web works. Teams spin up services constantly — staging environments, marketing landing pages, support portals, documentation sites — and when those services get shut down, DNS records are rarely the first thing anyone thinks about.
The problem is that a forgotten DNS record isn't just clutter. It can be a serious security vulnerability.
What's the risk?
When a subdomain points to an external service via a CNAME record, and that service is no longer configured, an attacker can register the unclaimed service and take control of your subdomain.
This is called a subdomain takeover.
staging.yourcompany.com → CNAME → old-app.herokuapp.com → ❌ unclaimed
An attacker who notices this can register old-app.herokuapp.com and immediately control what appears at staging.yourcompany.com — a URL that looks completely legitimate to anyone visiting it.
From there they can serve phishing pages, steal session cookies, bypass Content Security Policy, or just damage your brand.
It sounds obscure, but it appears regularly in bug bounty reports and has been found on domains belonging to major companies.
Step 1 — Discover all your subdomains
Before you can audit your DNS records, you need to know what subdomains exist. Most teams don't have a complete inventory.
Certificate Transparency logs are the easiest starting point. Every SSL certificate issued for your domain is publicly logged, which means you can query these logs to find subdomains that have had certificates issued.
Go to crt.sh and search for %.yourdomain.com — it will return every subdomain that's ever had a certificate.
Alternatively, tools like SubdomainChecker have an Enumerate mode that does this automatically — enter your root domain and it queries certificate transparency logs and checks each subdomain for takeover vulnerabilities in one step.
What you're looking for:
- Subdomains you don't recognize
- Subdomains for services you no longer use
- Old staging, dev, or test environments
Step 2 — Check each subdomain's CNAME records
For each subdomain, check what it points to. You can do this with dig or nslookup:
dig CNAME staging.yourcompany.com
Look at what the CNAME points to. Ask yourself:
- Is this service still active?
- Do we still use this service?
- Who owns this service account? If you can't answer these questions confidently, that subdomain needs attention.
Step 3 — Check for takeover fingerprints
For each subdomain that points to an external service, visit the URL and look at what it returns. Most platforms return a specific error page when a service is unconfigured:
| Service | Vulnerable fingerprint |
|---|---|
| GitHub Pages | "There isn't a GitHub Pages site here" |
| Heroku | "No such app" |
| AWS S3 | "NoSuchBucket" |
| Vercel | "The deployment could not be found" |
| Netlify | "Not Found - Request ID" |
| Zendesk | "Help Center Closed" |
| Shopify | "Sorry, this shop is currently unavailable" |
If you see one of these messages on your own subdomain — it's vulnerable.
Doing this manually for every subdomain is tedious. SubdomainChecker automates this — it follows the full CNAME chain, checks fingerprints against 80+ services, and tells you exactly which subdomains are vulnerable and why.
Step 4 — Fix vulnerable subdomains
For each vulnerable subdomain you find, you have two options:
Option A — Delete the DNS record
If you no longer need the subdomain, just remove the CNAME record from your DNS settings. This is the cleanest fix.
Option B — Reconfigure the service
If you still need the subdomain, reconfigure the external service properly so the subdomain points to an active, claimed resource.
Either way, act quickly. A dangling CNAME is a ticking clock.
Step 5 — Set up ongoing monitoring
A one-time audit isn't enough. New subdomains get created and services get decommissioned all the time. The fix is to make DNS auditing part of your regular process.
A few practical approaches:
Add it to your offboarding checklist — whenever a service gets decommissioned, DNS cleanup should be one of the first steps, not an afterthought.
Run periodic checks — set a calendar reminder to run a subdomain takeover check every quarter, especially after infrastructure changes or migrations.
Automate it — if you have a larger infrastructure, use the SubdomainChecker API to run automated checks as part of your CI/CD pipeline or security monitoring workflow. The API has a bulk endpoint that checks up to 25 subdomains per request.
The 10-minute audit
If you want to do a quick audit right now:
- Go to crt.sh and search
%.yourdomain.com - Copy the list of subdomains
- Paste them into SubdomainChecker using Bulk mode
- Review any results flagged as VULNERABLE or UNKNOWN Or use Enumerate mode to do steps 1-3 automatically.
The whole thing takes about 10 minutes. For most small to medium websites, you'll either find nothing (good) or find one or two forgotten subdomains that need cleanup (also good — better you find them than an attacker).
Summary
- Subdomain takeovers happen when a CNAME points to an unclaimed external service
- They're common because DNS cleanup is easy to forget
- Discovery: use certificate transparency logs to find all your subdomains
- Detection: check CNAME targets and look for known vulnerable fingerprints
- Fix: delete the DNS record or reconfigure the service
- Prevention: make DNS auditing part of your regular process
Top comments (0)