Subdomain Finder

Mainly from certificate transparency logs. Every publicly trusted TLS certificate is published to append-only public logs, and a certificate names the hosts it covers, so reading the logs reveals subdomains that genuinely exist. That source is entirely passive: it sends nothing at all to the domain you are looking up. The optional common-name list adds a few DNS queries for hosts that never had a public certificate.

The certificate transparency source does not - it reads a public log. The common-name option makes DNS queries, which reach the domain's nameservers; that is around a hundred queries, fewer than a browser makes loading one news site. Nothing here connects to the hosts it finds: no HTTP requests, no port scanning. That limit is deliberate, not unfinished.

A CNAME that points at a hostname which no longer resolves. It usually means a service was decommissioned but the DNS record was left behind. If someone else can claim that service name, they can serve content on your subdomain - a subdomain takeover. Finding these on your own domains is the main defensive reason to run this tool.

Certificate transparency only shows hosts that were given a publicly trusted certificate. A subdomain behind a wildcard certificate, on plain HTTP, or using a private CA leaves no trace in the logs. The common-name list catches some of those, but no passive method finds everything, and this tool does not guess exhaustively.

Yes, on purpose. Discovery is capped at 200 names per request with a total time budget, so one lookup cannot occupy the server or flood a nameserver. When the cap is reached the result says so, and names seen in a real certificate are kept ahead of guesses.