Finds the domain's subdomains, resolves their DNS, and checks each name against two takeover detectors.
A finding is a dangling CNAME pointing at a service nobody owns.
Target
One domain per line. Default example.com.
Results
A PDF of confirmed takeovers plus the full subdomain inventory.
Also writes report.json.
Overview
Subdomains outlive the things they point at. A marketing site moves, a staging
bucket is deleted, a SaaS trial lapses, and the DNS record stays behind pointing
at a hostname nobody owns any more. Anyone who registers that hostname now serves
content on your domain, with your certificate story and your users' trust.
This finds those records before someone else does. You get an inventory of every
subdomain that resolves, and for the dangling ones, the service sitting behind the
CNAME, which is what tells you whether the record is claimable and who to ask for
it back. That makes it a standing check for
exposure management rather than a one-off audit,
because the gap opens the day a service is decommissioned, not the day you look.
Two detectors run over the same resolved set and their findings are merged, so a
record missed by one signature is still caught by the other.
Pipeline
Read the target domains.
subfinder enumerates subdomains from passive sources.
subzy and a nuclei takeover template set run
over the resolved hosts in parallel, each batch distributed across the fleet.
Findings from both detectors merge and deduplicate into one report.
Inputs
Target domains. One root domain per line, such as example.com. The
default is the IANA example domain, so a run you start without editing
anything points at nothing you would have to explain.
subfinder API keys. Optional config file. Passive enumeration works
without one, and adding keys widens the set of subdomains that reach the
takeover checks.
nuclei takeover templates. Pulled fresh at run time. Leave this alone
unless you keep a private template set you want used instead.
Rate limit and concurrency. Defaults suit a normal perimeter. Lower them
on targets where a burst of DNS and HTTP requests would be noticed.
Outputs
Dangling records. Each finding as the subdomain, the CNAME it points at,
and the fact that nothing answers on the other end.
Service attribution. The vendor behind each dangling CNAME, labelled from
the can-i-take-over-xyz fingerprint set. This is what tells you whether the
record is claimable and who to ask for it back.
Resolved subdomain inventory. Every subdomain that resolved, with its
CNAME chain. You get this even when the takeover count is zero.
PDF report. Both detectors merged and deduplicated into one document,
with the inventory attached.
Nothing dangling on this domain, which is the result you want. On a surface that
has been running for a few years, it rarely is.
FAQ
What makes a record dangling?
The CNAME still resolves inside your zone, but the hostname it points at is
unregistered. Anyone who claims that hostname then serves content on your
subdomain, using a name your users and your certificates already trust.
Why run two detectors over the same hosts?
subzy and the nuclei takeover templates carry
different fingerprint sets, and neither covers every service. Running both and
merging means a record one signature does not know about is still caught by the
other.
Does a flagged subdomain always mean I can take it over?
No. The run tells you the record is dangling and names the service behind it.
Whether it is claimable depends on that provider's registration rules, which is
why the service label ships in the output rather than a bare verdict.
How often should I run this?
On a schedule, weekly or tighter. The gap opens the day a service is
decommissioned, not the day you audit, so the value is in catching the record in
between.
Does this send traffic to the target?
The enumeration step is passive. The resolve and takeover checks make DNS
queries and HTTP requests to the subdomains themselves, which are hosts in your
own zone.
Related workflows
Subdomain Enumeration. Reach for this
instead when you need a complete subdomain list first, because dangling
records only mean something against an inventory you trust.
Find Origin IPs Behind Cloudflare.
Reach for this instead when the CNAMEs all point at a CDN and the question is
what sits behind it, not who can claim it.