How subdomain discovery works

The problem being solved

A large organisation might have example.com as its public site, while quietly operating api.example.com, admin.example.com, staging.example.com and several hundred more. None of that is linked from the homepage, and none of it is in any directory. Historically, the only ways to learn it existed were to guess common names, or to scan the network, which is slow and legally fraught.

Certificate Transparency, or CT, removed that problem for anyone who owns a website. Since around 2017, browsers have required that a publicly trusted certificate only be issued after its domain names are published to a set of public, append-only logs. The result is that issuing a certificate for staging.example.com effectively announces that host to the entire internet.

What a CT log actually records

A log entry is not a copy of your certificate's private key or its contents. It records the identity information from a certificate: the domain names it covers, who issued it, and when. The log is append-only, meaning entries can be added but never edited or deleted, and it is served over an unauthenticated public endpoint, which is what makes it useful for this kind of lookup.

This tool queries crt.name, a public search interface over those logs. It does no scanning of its own.

Why old, dead subdomains still show up

This is the single most common surprise for people using a CT-based finder, and it is worth understanding clearly.

Logs never remove entries. If your team issued a certificate for beta.example.com in 2019, then deleted the host in 2020, that name is still in the log in 2026. TLS certificate revocation operates at the certificate level, not the hostname level, so deleting a server does not remove the historical record of the name.

Practically, this means a subdomain finder is as much a tool for finding forgotten infrastructure as it is for finding current infrastructure. A result that no longer resolves is not necessarily harmless, which is covered in the next section.

Why abandoned subdomains are a genuine risk

A retired hostname is only truly gone if nothing can claim it. There are two common failure modes:

• Dangling DNS. A CNAME record still points at a third-party service, such as a hosting provider or a form-handling platform, whose account has lapsed. An attacker who claims that abandoned account can start serving content under your domain.
• Sub-delegated zones. A subdomain delegated its own zone, so the record pointing at it still exists after you stop using it, and the name can be re-registered by someone else.

Both are preventable. The fix in each case is to delete the DNS record, not merely to stop using the host. See the FAQ for specifics on removal.

What this method cannot find

Being clear about the limits is what separates a useful tool from an overpromising one. A CT finder will not show you:

• Subdomains with no publicly trusted certificate. Internal tools, services on private networks, and anything using a self-signed or private CA certificate are invisible here.
• Names hidden behind wildcards. A wildcard certificate for *.example.com covers arbitrary subdomains without each one appearing in the log. You will see the wildcard, not the hosts it covers.
• Anything not yet published. CT logs are eventually consistent, so a certificate issued seconds ago may not be searchable yet.

For a complete picture of your own estate, combine this with your DNS zone data and internal inventories. For an external view, this is close to the best public data available.

Other ways subdomains get discovered

CT logs are the strongest single source, but they are one of several. In practice, thorough enumeration combines:

Method	What it finds	Limitations
Certificate Transparency	Every host with a publicly trusted certificate	Misses uncertificated and internal hosts
Passive DNS	Historical resolutions, including retired hosts	Commercial, and often partial coverage
Search engines	Publicly indexed pages, occasionally leaked paths	Incomplete and slow to update
DNS brute forcing	Guessed names, including uncertificated ones	Noisy and slow; looks like an attack
Zone transfer	The complete authoritative list	Only your own domain, and only if misconfigured

Reducing your own exposure

You cannot remove history from a CT log, and you should not want to: the log is what makes certificates trustworthy. What you can do is remove the underlying risk.

1. Find the subdomains you no longer use.
2. Delete their DNS records outright, including any sub-delegated zones.
3. Shut down hosts that are still running, and remove them from any load balancer or CDN config.
4. Replace wildcard coverage with explicit names where you can, so future issuance is visible.
5. Add HSTS preload and CAA records to constrain what can be issued for your domain.

A subdomain finder is the fastest way to take the first step, and the glossary explains what the names you find actually mean.