← Back to the Subdomain Takeover Checker
Running dig CNAME blog.example.com is a real, fast way to see where a hostname
points. It is also the method most developers already reach for first, and it genuinely shows
you the target.
| Check | dig by hand | This tool |
|---|---|---|
| Seeing the CNAME target | Catches it | Catches it |
| Recognising the target as one of ~25 known takeover-prone providers | You have to already know the pattern (which of dozens of hostnames like *.herokuapp.com, *.s3.amazonaws.com, *.azurewebsites.net actually matter) | Matched against a maintained provider table automatically |
| Following a multi-hop CNAME chain to its real end | Manual, one dig per hop | Followed automatically, up to 8 hops |
| Confirming the target is actually unclaimed right now, not just provider-shaped | Requires a second manual step: opening the URL and reading the response | One live GET request, checked against that specific provider's own "unclaimed" fingerprint page |
| Checking a whole list of hostnames in one run, repeatable in CI | Manual, one at a time | CLI accepts multiple hostnames and returns a real exit code |
If you only need to see where one hostname currently points, dig is fine — it's
already on your machine and you're already there. The gap this tool closes is recognition and
confirmation: knowing which of the target's dozens of possible shapes actually matters, and
proving the name is genuinely unclaimed with a live fingerprint match rather than assuming risk
from the DNS target's shape alone.
dig CNAME blog.example.com shows you the CNAME target — a real, fast way to see where a hostname points. It does not tell you whether that target is one of the roughly two dozen hosting providers known to let an unclaimed name be claimed by anyone, and it does not tell you whether the target is actually unclaimed right now versus in active, legitimate use.
Three ways this scripted check catches and a quick dig lookup misses: (1) recognising which of dozens of possible CNAME target patterns actually belongs to a takeover-prone provider — a hostname like old-app.herokuapp.com means nothing to dig, which just prints the string. (2) Following a multi-hop CNAME chain to its real end rather than stopping at the first hop. (3) Confirming the target is genuinely unclaimed with a live HTTP request checked against that specific provider's own "nothing is claimed at this name" page — a CNAME pointing at a provider is not proof of anything on its own; plenty of CNAMEs to Heroku or S3 are perfectly legitimate and in active use.
A manual dig is a point-in-time look at one hostname you already thought to check. A decommissioned service, a provider migration, or a sunset campaign page can leave a new dangling record behind at any point. The CLI here returns a real exit code across as many hostnames as you give it in one run, so it can gate a periodic DNS-zone audit the same way a linter gates a deploy.