DEV Community: Mika

How to Audit Your DNS Records for Subdomain Takeover Vulnerabilities

Mika — Wed, 13 May 2026 19:37:11 +0000

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 10 Services Most Vulnerable to Subdomain Takeover (And How to Detect Them)

Mika — Tue, 28 Apr 2026 11:51:54 +0000

Subdomain takeovers are one of the most underrated vulnerabilities in web security. They're easy to miss, surprisingly common, and can have serious consequences — phishing pages served under your own domain, session cookie theft, or brand damage.

The attack always follows the same pattern: a subdomain points to an external service via a CNAME record, the service gets deprovisioned, but nobody removes the DNS record. The subdomain is now dangling — and claimable by anyone.

Here are the 10 services where this happens most often, along with the fingerprint that gives it away.

1. GitHub Pages

Fingerprint: There isn't a GitHub Pages site here

GitHub Pages is one of the most common culprits. Developers frequently set up docs.example.com or blog.example.com pointing to a GitHub Pages site, then delete the repository or disable Pages without removing the CNAME record.

Anyone can create a GitHub Pages site at the dangling address and immediately serve content under your subdomain.

Example CNAME chain:

docs.example.com → username.github.io → ❌ unclaimed

2. Heroku

Fingerprint: No such app

Heroku is a classic. Staging environments, side projects, and old prototypes frequently get deleted while their DNS records live on. The "No such app" page is one of the most recognizable takeover signals in bug bounty hunting.

Example CNAME chain:

staging.example.com → old-app.herokuapp.com → ❌ unclaimed

3. AWS S3

Fingerprint: NoSuchBucket

S3 buckets configured for static website hosting are highly susceptible. When a bucket is deleted, the subdomain pointing to it becomes claimable by anyone who creates a new bucket with the same name in the same region.

This one is particularly dangerous because S3 buckets can serve arbitrary files — including HTML pages and scripts.

Example CNAME chain:

assets.example.com → example-assets.s3-website-us-east-1.amazonaws.com → ❌ bucket deleted

4. Vercel

Fingerprint: The deployment could not be found

Vercel deployments are spun up and torn down constantly. When a project gets deleted or a custom domain gets removed from a Vercel project without cleaning up DNS, the subdomain dangles.

Example CNAME chain:

app.example.com → cname.vercel-dns.com → ❌ project deleted

5. Netlify

Fingerprint: Not Found - Request ID

Same story as Vercel. Netlify sites get deleted all the time — marketing landing pages, campaign microsites, A/B test variants. The DNS record outlives the site.

Example CNAME chain:

landing.example.com → example.netlify.app → ❌ site deleted

6. Azure

Fingerprint: 404 Web Site not found

Azure has multiple vulnerable services — App Service, Front Door, CDN, Traffic Manager. Enterprise companies running on Azure often have dozens of subdomains pointing to Azure resources, and decommissioning processes don't always include DNS cleanup.

Example CNAME chain:

portal.example.com → example.azurewebsites.net → ❌ app deleted

7. Shopify

Fingerprint: Sorry, this shop is currently unavailable

E-commerce businesses frequently set up custom subdomains for their Shopify stores — shop.example.com or store.example.com. When they migrate platforms or shut down the store, the CNAME often stays.

Example CNAME chain:

shop.example.com → example.myshopify.com → ❌ shop closed

8. Zendesk

Fingerprint: Help Center Closed

Support portals are a goldmine for subdomain takeovers. Companies set up help.example.com or support.example.com pointing to Zendesk, then migrate to a different support platform without cleaning up DNS.

A takeover here is particularly dangerous — users trusting a support subdomain might enter credentials or sensitive information.

Example CNAME chain:

help.example.com → example.zendesk.com → ❌ account closed

9. Ghost / Ghost.io

Fingerprint: Domain not configured

Ghost is a popular blogging platform. blog.example.com pointing to a Ghost instance is extremely common, and when companies rebrand or migrate their blog, the DNS record is often forgotten.

Example CNAME chain:

blog.example.com → example.ghost.io → ❌ site not configured

10. Fastly

Fingerprint: Fastly error: unknown domain

CDN takeovers are less common but high impact. Fastly serves content for massive amounts of web traffic, and a dangling CNAME to a Fastly endpoint means an attacker could potentially intercept or serve content to users expecting your site.

Example CNAME chain:

cdn.example.com → example.global.ssl.fastly.net → ❌ service not configured

How to detect these vulnerabilities

Detection comes down to two things:

1. Check for NXDOMAIN
Follow the full CNAME chain. If the final destination returns NXDOMAIN — the domain doesn't exist in DNS — you have a dangling CNAME regardless of the service.

2. Check for service fingerprints
If the target resolves but returns one of the error messages above, the service exists but isn't configured for that domain. That's your takeover signal.

You can check any subdomain automatically using SubdomainChecker — it follows CNAME chains, checks fingerprints against 80+ services, and even enumerates subdomands from certificate transparency logs so you don't have to find them manually.

There's also a free API if you want to integrate takeover detection into your own recon pipeline: RapidAPI

How to protect yourself

Keep a DNS inventory — know what every subdomain points to
Remove DNS records before decommissioning services — DNS cleanup should be step one, not an afterthought
Audit regularly — run a takeover check every few months, especially after infrastructure changes
Automate it — use the API to run checks automatically as part of your CI/CD pipeline or security monitoring

Subdomain takeovers are preventable. The vulnerability only exists because of forgotten DNS records — and a 30-second check is all it takes to find them.

I Ran a Subdomain Takeover Checker on GitHub.com and Found a Vulnerable Subdomain

Mika — Wed, 22 Apr 2026 19:23:42 +0000

I've been building a tool that checks subdomains for takeover vulnerabilities. Yesterday I decided to test it on a well-known target — github.com — just to see what it would find.

I wasn't expecting much. GitHub is a massive, well-maintained platform with a serious security team. But within seconds of running the enumeration, one result came back red:

brandguide.github.com — VULNERABLE
Service: github.io
Reason: Unconfigured fingerprint found for github.io

What does this mean?

brandguide.github.com has a CNAME record pointing to a GitHub Pages address that is no longer configured. The page returns GitHub's classic "There isn't a GitHub Pages site here" message — which is the exact fingerprint that indicates an unclaimed Pages site.

In theory, anyone could create a GitHub Pages site at that address and serve content under brandguide.github.com — a subdomain that looks like it belongs to GitHub.

This is a textbook subdomain takeover.

How the tool found it

The tool uses two steps to detect takeovers:

Step 1 — Enumerate subdomains via certificate transparency logs
Certificate authorities are required to publicly log every SSL certificate they issue. By querying crt.sh, you can discover subdomains that have had certificates issued — no scanning, no probing, just reading public records.

For github.com this returned dozens of subdomains instantly.

Step 2 — Check each subdomain for takeover vulnerabilities
For each subdomain, the tool follows the full CNAME chain. If the final destination returns NXDOMAIN (the domain doesn't exist) or matches a known "unconfigured" fingerprint from services like GitHub Pages, Heroku, Vercel, AWS S3, and 80+ others — it flags the subdomain as vulnerable.

brandguide.github.com passed through the CNAME chain check and matched the GitHub Pages fingerprint. Result: vulnerable.

This happens more than you think

GitHub is not unique here. Subdomains get created for marketing campaigns, staging environments, documentation sites, and internal tools — then the service gets decommissioned, but nobody cleans up the DNS record.

It's not a sign of negligence. It's just the natural entropy of running infrastructure at scale. The DNS record outlives the service by months or years, quietly waiting for someone to notice.

What I did with the finding

Nothing — I don't own github.com and have no intention of claiming the subdomain. This article is purely educational. If you work at GitHub and are reading this, consider this a friendly heads up.

If you want to check your own domains, the tool is free to use:

🔗 subdomainchecker.com — paste in a root domain, it enumerates subdomains via crt.sh and checks each one automatically

There's also a public API if you want to integrate it into your own recon pipeline:

🔗 RapidAPI — Subdomain Takeover Checker — free tier available

TL;DR

Subdomain takeovers are real and happen even at large companies
Certificate transparency logs are a goldmine for passive subdomain enumeration
Automated fingerprint checking makes it trivial to scan dozens of subdomains in seconds
Always clean up your DNS records when you decommission a service

Subdomain takeovers are still embarrassingly common...

Mika — Sun, 19 Apr 2026 13:04:44 +0000

You've probably heard of domain hijacking — but subdomain takeovers are sneakier, more common, and surprisingly easy to miss.

What is a subdomain takeover?

When a company sets up a service like a blog, a shop, or a staging environment, they often point a subdomain at an external platform using a DNS record called a CNAME.

For example:

shop.example.com → CNAME → example.myshopify.com

This tells the internet: "when someone visits shop.example.com, send them to our Shopify store."

Now imagine the company shuts down that Shopify store — but forgets to delete the DNS record. The CNAME is still there, pointing at a Shopify address that no longer exists.

An attacker can register that Shopify store and suddenly controls shop.example.com. They can serve phishing pages, steal cookies, or damage the brand — all from what looks like a legitimate company subdomain.

Why does this keep happening?

Because DNS cleanup is boring and easy to forget. Teams spin up new services all the time — staging environments, marketing landing pages, support portals — and when those services get decommissioned, the DNS records are often left behind.

It's not a sophisticated attack. It just requires patience and a good eye for dangling CNAMEs.

How do you detect it?

Detection comes down to two steps:

Step 1 — Follow the CNAME chain
Resolve the subdomain and follow every CNAME until you reach the final destination. If the final target returns NXDOMAIN (the domain doesn't exist in DNS), that's a strong signal of a dangling CNAME.

Step 2 — Check for service fingerprints
If the target resolves but the service isn't configured, most platforms return a recognizable error page. For example, an unclaimed GitHub Pages site returns "There isn't a GitHub Pages site here". Checking for these fingerprints confirms whether a takeover is possible.

One important caveat: wildcard DNS can cause false positives. If a parent domain resolves any random subdomain (like random123.example.com), you need to account for that before flagging something as vulnerable.

Checking your own subdomains

If you're a developer or sysadmin, it's worth periodically auditing your DNS records — especially for subdomains pointing at third-party services you may have stopped using.

I built a free API that automates this entire process. It follows CNAME chains, checks fingerprints against 80+ services (AWS S3, Azure, Heroku, Vercel, Netlify, GitHub Pages, Shopify, Zendesk and more), handles wildcard detection, and returns a confidence level with each result.

There's also a bulk endpoint that checks up to 25 subdomains at once — useful if you have a large number of subdomains to audit.

You can try it here: Subdomain Takeover Checker API — free tier available, no credit card needed.

Or check out the website: subdomainchecker.com

TL;DR

Subdomain takeovers happen when a CNAME points to an unclaimed external service
They're common because DNS records are rarely cleaned up when services are decommissioned
Detection involves checking for NXDOMAIN and known service fingerprints
Audit your subdomains regularly — especially after decommissioning any third-party service