Subdomain takeover
A subdomain takeover happens when a DNS record still points at a hosting service that no longer has anything on it. Whoever claims that service name next controls what your subdomain serves. The record outliving the service is the entire bug.
Contents
How does a subdomain end up claimable?
Someone points a subdomain at a hosted service, uses it for a while, then deletes the service and leaves the DNS record behind. The name on the provider is now free. Anyone who registers it receives every request for your subdomain, because your own DNS is still sending them there. Nothing is compromised on your side and nothing shows up in your logs, which is why these survive for years.
What can somebody actually do with it?
Serve whatever they like under a name your users trust, which is a phishing page with real domain provenance and a valid certificate. If any cookie on the parent domain was scoped with a leading dot, the subdomain can read it, and a session cookie read from a subdomain is a session. It is also enough to pass domain-verified sign-ups and to send mail that inherits your reputation.
Why do the checks distinguish NXDOMAIN from an unclaimed service?
They are different problems with different urgency. A record whose target does not resolve at all is dangling and exploitable only if the target can be registered. A record whose target resolves to a provider that is answering "no site here" is a confirmed claimable service, and the window is however long it takes someone else to type the name. The second is the one to treat as urgent.
What is the fix?
Delete the DNS record. That is the whole fix, and it is the only one that is durable, because reclaiming the service on the provider just moves the same problem to whenever that account lapses. The larger fix is process: whatever tears down a service has to remove the record in the same step, or the gap reopens on the next decommission.
Every finding, and what it means
2 checks, each with what it is, why it matters and the fix. Every one has its own link, so a finding can be sent to whoever owns the fix without sending the whole page.
The record points at a name that does not exist
- What it is
- This subdomain has a CNAME pointing at a hostname that no longer resolves at all.
- Why it matters
- The record points into nothing. If the provider behind that name lets anyone register it, whoever does gets to serve content on your subdomain. This is the strongest signal of a takeover risk and does not depend on us recognising the provider.
- How to fix it
- Delete the DNS record. If you still need the subdomain, recreate the resource at the provider first, then confirm the record resolves to it.
The provider is serving its "not configured" page
- What it is
- The subdomain points at a recognised hosting provider, and that provider is returning the page it shows for a host nobody has claimed.
- Why it matters
- The resource this record was created for is gone, but the record is not. Depending on the provider, someone else may be able to claim the name and serve content on your subdomain.
- How to fix it
- Remove the record, or recreate the resource at the provider so the name is yours again. Check how the provider handles domain verification to judge the urgency.
Frequently asked
How do I find these across a domain I did not set up?
Enumerate the subdomains first, from certificate transparency logs and passive DNS, then resolve each one and look at what answers. The records that matter are the ones pointing somewhere that no longer serves anything, and they are almost never in whatever inventory the team believes is current.
Is a fingerprint match proof that a subdomain is claimable?
No, and confident wrong answers are the known failure of every takeover checker, including this one. Providers change their "no site here" pages, and a stale fingerprint reads a normal 404 as a claimable service. Treat a match as a reason to check the provider, not as a finding to report onward.
Does this only affect CNAME records?
CNAMEs to hosting providers are the common case because that is how most services are wired up. The same problem exists for an A record pointing at an IP address you released back to a cloud provider, where whoever is allocated it next receives your traffic.
Run this against a domain you own. Start free