Paste the CNAME or ALIAS target a subdomain points at, and the error page you see when you visit it. This tool matches both against a built in fingerprint list of well known third party services and tells you when the pair looks like a claimable dangling resource. It does not contact your domain.
Most teams park subdomains on third party platforms. A docs site lives on a static host, a status page lives on a status provider, a marketing landing page lives on a website builder. You point a subdomain at the provider with a CNAME or ALIAS record, the provider serves it, and everyone moves on. The trouble starts when the hosted asset is deleted but the DNS record is left behind. Now you have a dangling record: a name on your domain that still routes to a provider slot nobody owns.
An attacker who notices that dangling record registers the same resource on the provider, often by claiming the exact host name your record points at. Because your DNS still routes traffic to the provider, and the provider now hands that slot to the attacker, your subdomain serves whatever they upload. No DNS spoofing, no certificate trickery, just a reclaimed slot on a shared platform. The community maintained can i take over xyz list catalogs which providers are vulnerable, which are fixed, and which are conditional, and the fingerprint database in this tool draws on that public knowledge.
The damage is larger than a defaced page because the subdomain is genuinely yours. Visitors trust it, and so do parts of your own stack. An attacker can stand up a convincing phishing page on a name that carries your brand. They can read or set cookies scoped to the parent domain when those cookies are not locked down, which bleeds into session handling across your apps. They can register the subdomain as an allowed redirect or origin in an OAuth or single sign on flow and quietly intercept tokens. A name you forgot becomes attacker controlled real estate inside your trust boundary.
Two signals usually identify a takeover. The first is the host the subdomain points at: a CNAME ending in a known provider suffix such as github.io, s3.amazonaws.com, or herokudns.com tells you which platform is in play. The second is the error the provider returns for an unclaimed slot, a recognizable string such as There isn't a GitHub Pages site here. or NoSuchBucket. This tool compares the CNAME you paste against a list of provider host patterns and compares the error text you paste against documented dangling state messages. When a CNAME pattern and a matching dangling fingerprint line up, the slot is very likely claimable. When only one matches, the tool says so and tells you what to check next.
Because the matching is text against a built in list, the result is only as complete as that list. A clean result means nothing in the database matched, not that the subdomain is safe. New providers appear, error pages change, and some services only allow a takeover under narrow conditions. Treat a match as a lead to verify, the way an AI security testing approach reasons about a finding rather than trusting a single pattern.
The durable fix is to keep DNS and hosted assets in step. When you decommission an asset on a provider, delete the DNS record that points at it in the same change, not later. Audit your zones for records that resolve to third party hosts and confirm each one still maps to a resource you own and have verified. For platforms that support it, claim and verify the resource so no one else can register it under your name. Then monitor: watch for new dangling records and for provider error pages appearing on names that should be live. The broader practice of pinning what your domain trusts is the same instinct that drives the rest of web application security.