Subdomain Takeover Checker

Paste a hostname. This follows its real CNAME chain over public DNS, and when the chain ends at one of 25 known takeover-prone providers, sends one live GET request and checks the response against that specific provider's own "nothing is claimed at this name" page — a confirmed finding, not a guess from DNS alone. See why CNAMEs end up dangling for the common causes and the fix. This tool never attempts to claim, register, or configure anything at any provider — detection and reporting only. Only run this against a hostname you own or are authorised to test.

Run the check

Enter a hostname, then click Check.

Prefer a CLI, or hit a CORS wall in the browser?

The DNS lookup always completes (Cloudflare's resolver answers CORS-enabled), but most third-party providers don't send permissive CORS headers on their catch-all "not found" page, so the confirming GET request often cannot complete from a browser tab — you'll see the finding reported as unconfirmed rather than confirmed. The CLI has no such restriction and is the one path guaranteed to complete: 

node check.mjs blog.example.com --json

Get check.mjs, lookup.mjs, probe.mjs, fingerprints.mjs, and analyze.mjs from the repo — exit code 1 if any hostname is confirmed or unconfirmed-risky, so you can gate a deploy or a DNS-zone review on it.

Common questions

What is a subdomain takeover?

A DNS CNAME record on your domain still points at a third-party service (an S3 bucket, a Heroku app, a GitHub Pages site), but whatever used to be configured there has since been deleted or was never created. Many of those services let anyone claim an unclaimed name on their platform — and once they do, they can serve their own content under your subdomain, complete with your domain's own cookies and any trust your CSP or CORS policy places in it.

How does this tool confirm a takeover risk rather than just guessing from DNS?

It follows the hostname's CNAME chain over real DNS first. If the chain ends at a hostname matching one of 25 known takeover-prone providers, it sends one live GET request to your hostname and checks the response against that specific provider's own "nothing is claimed at this name" page text. Only a match on both — the CNAME target and the live response — is reported as confirmed; a CNAME match with no confirming response is reported separately, as worth a manual look rather than proven. See how this compares to checking with dig by hand.

Does this tool claim the vulnerable name for me, or otherwise fix it?

No. It only detects and reports. Claiming the resource yourself (creating the S3 bucket, the Heroku app, the GitHub Pages repo under the exact name your CNAME expects) is the actual fix in most cases, alongside removing the DNS record if the subdomain is no longer needed at all — see the guide page for the walkthrough.

Is it safe to point this at a hostname?

This tool sends one DNS lookup and, only for a provider match, one ordinary GET request to the hostname you name — the same requests your own browser already makes when you visit it. It never attempts to claim, register, or write anything at any provider. It does not upload the hostname or anything it finds to our servers when run in the browser; every request goes straight from your browser to the DNS resolver and the target. Still, only run this against a hostname you own or are authorised to test.

Does a clean report mean my whole domain has no dangling CNAMEs?

It means the hostnames you checked in this run showed no CNAME risk this tool's 25-provider table could detect. This tool only checks the exact hostnames you give it — it does not enumerate your DNS zone or guess at other subdomains — and it only recognises the providers in its table. See README.md's coverage note for what that does and does not include.