Subdomain Finder

Since 2018 every certificate a browser trusts has to be logged in a public, append-only Certificate Transparency log. The system was built to catch mis-issued certificates, and it does that well, but it has an obvious side effect: a certificate names the hosts it covers, so publishing the certificate publishes the hostnames. Request a certificate for staging.example.com and that name is public within minutes, whether or not the host is meant to be found.

That makes CT the single richest source for subdomain discovery, and it is why this tool leads with it. It is also why the results skew historical. Logs are append-only, so a name from a decommissioned host in 2019 is still there today alongside the ones in production. The DNS check is what separates those two piles.

The gap in CT coverage is wildcards. One certificate for *.example.com covers every host at that level while naming none of them, so an organisation that standardised on wildcards leaves almost no CT trail. Passive DNS partly fills that in, since it indexes names that resolvers have actually been asked about, regardless of what certificate covers them.

Each discovered name is resolved for an A record over DNS-over-HTTPS, and the answer falls into three useful buckets. A name that resolves is a live host worth looking at. A name that exists but has no A record is usually AAAA-only, or a name carrying only MX or TXT records, which is common for mail and verification hostnames. A name with no DNS at all is history: the certificate outlived the host.

The interesting rows are often the ones in between. A subdomain that resolves through a CNAME to a cloud provider bucket or app platform, where the underlying resource no longer exists, is the classic subdomain takeover setup. The tool shows the CNAME target for exactly this reason, since the DNS answer alone does not tell you whether the thing at the other end is still claimed.

For your own domains, the value runs the other way. A list of every name your organisation has ever certified, filtered to what still resolves, is a quick inventory check: forgotten staging hosts, a dev environment nobody shut down, an old vendor integration still pointed at your DNS.

Everything here is passive. The tool reads public records from third-party APIs and never touches the domain you type, so running it against a domain is not a scan of that domain in any meaningful sense. That distinction matters legally and practically, and it is why the same lookups sit behind tools like crt.sh, which anyone can query without an account.

What you do with the list is a different question. Enumeration is the reconnaissance step; connecting to the hosts, scanning them, or testing them for weaknesses is activity directed at someone else's infrastructure and needs their permission, whether that comes from owning the domain, a signed engagement, or a published bug bounty scope.