How to Find All Subdomains of a Domain (Without Scanning)

A domain is rarely just one website. Behind example.com there is usually a www, a mail, an api, a blog, a staging server someone spun up two years ago, a vpn gateway, and a handful of names a marketing team registered for a campaign that ended long ago. Each of those is a subdomain, and together they make up the real surface area of an organisation on the internet.

If you run that domain, you want to know every name that points at your infrastructure — because you can't secure what you've forgotten you own. If you're investigating a domain from the outside, the subdomain list is the map you start from. Either way, the good news is that for most domains you can build that list without sending a single packet to the target, using data that's already public.

What a subdomain actually is#

DNS is hierarchical. Reading a name right to left, .com is the top-level domain, example.com is the registered domain, and anything to the left of it — mail.example.com, api.staging.example.com — is a subdomain. Each label adds a level. The owner of example.com controls the entire tree below it and can create as many subdomains as they like, each pointing wherever they want: a different server, a third-party SaaS app, a parked page, or nothing at all.

That freedom is exactly why subdomains sprawl. There's no central registry of them — no equivalent of WHOIS that lists every subdomain a company uses. A subdomain exists the moment someone adds a DNS record for it, and it can be created and abandoned without anyone outside the team ever noticing. If you want the full picture, you have to reconstruct it from whatever traces those subdomains left behind. (If the parent registration itself is what you're after, that's a WHOIS lookup — a different question.)

Why you'd want the full list#

The motivation is almost always about surface area.

• Asset inventory. Security teams can only defend hosts they know exist. The first step of nearly every audit is "find everything we have on the internet," and forgotten subdomains — old admin panels, test environments, demo apps — are where the embarrassing exposures hide.
• Subdomain takeover hunting. A subdomain with a CNAME pointing at a cloud service that's since been deleted is a dangling record. Anyone who re-registers that service name can serve content from your subdomain. Finding these before an attacker does is one of the highest-value uses of a subdomain list.
• Reconnaissance and due diligence. Penetration testers, bug-bounty hunters, and analysts use the subdomain map to understand how an organisation is structured and where the interesting systems live.
• Migration and cleanup. Before you move providers or retire a domain, you need to know every name that still resolves so nothing breaks silently.

Passive vs active discovery#

There are two broad ways to find subdomains, and the difference matters.

Active discovery means asking DNS directly: take a wordlist of likely names (dev, vpn, git, portal…), query each one, and keep the ones that resolve. It's thorough for common names, but it's also noisy — you're generating traffic aimed at the target's nameservers, it only finds names you thought to guess, and it can take a long time for a large wordlist. The old shortcut, a DNS zone transfer that dumps every record at once, is closed off on virtually every properly configured server today.

Passive discovery means never touching the target at all. Instead you query third-party datasets that have already recorded the domain's subdomains as a side effect of normal internet activity — search engines, passive-DNS aggregators, and, most usefully, Certificate Transparency logs. Passive discovery is quiet, fast, and finds real names you'd never have guessed. Its limitation is that it can only surface what some public dataset happened to record.

How Certificate Transparency hands you the list#

This is the trick that makes free subdomain discovery work so well. Since 2018, browsers have refused to trust a TLS certificate unless it has been published to a public, append-only Certificate Transparency log. The system exists so that misissued or rogue certificates can be caught in the open — but it has a powerful side effect: every certificate a domain requests becomes a permanent public record, and certificates list the hostnames they cover.

When a company gets a certificate for secure-checkout.example.com, the hostname goes into the certificate's Subject Alternative Name field, the certificate gets logged, and from that moment on anyone can read it. You don't need access to the company's DNS, its servers, or its account anywhere. You just search the logs for everything ever issued under example.com and collect the names. Because almost everything runs over HTTPS now — every login page, API, and internal tool that listens on port 443 needs a valid certificate — the CT logs end up holding a remarkably complete inventory of an organisation's named hosts. If you want the underlying theory of how these logs work and why they exist, we wrote a full explainer on Certificate Transparency.

Our subdomain finder does exactly this: it queries the public CT logs for a domain, pulls every hostname out of the certificates, deduplicates them, and hands you a clean, sorted list you can copy or download — passively, with nothing sent to the target. If you'd rather look at the raw certificates themselves, the CT log search tool shows each issuance individually.

What this method misses — honestly#

No subdomain technique finds everything, and it's worth being precise about the blind spots rather than pretending the list is complete.

• Names that never got their own certificate. A purely internal host that only listens on a private network, or a subdomain served over plain HTTP with no TLS, may never appear in any CT log.
• Wildcard certificates. If an organisation secures everything with a single *.example.com wildcard certificate, the log shows the wildcard — not the individual hostnames behind it. The names are real and live; CT just can't see them. This is the single biggest gap in CT-based discovery.
• Dead names. CT is a historical record, so it will surface subdomains that were certified once and no longer resolve. That's useful for takeover hunting, but it means a raw CT list mixes live and retired hosts together.

The practical takeaway: Certificate Transparency is the best single starting point for subdomain discovery, and for many domains it's enough on its own. For a genuinely exhaustive map you'd combine it with active resolution and other passive sources — but you start with CT because it's free, instant, and quiet.

Turning a raw list into something useful#

A list of two hundred hostnames isn't an answer by itself. The next step is to figure out which ones are live and what they point at. Run the candidates through a DNS lookup to see which still resolve and to what — a host with no current A, AAAA, or CNAME record is either retired or, if it has a dangling CNAME, a potential takeover. Our DNS records lookup resolves any name across the record types in one shot, and if you want to understand what each of those record types means, the guide to DNS record types walks through all of them.

From there, the resolving subdomains are your real attack surface. Group them by where they point — your own IP ranges, a CDN, a SaaS provider — and the unexpected ones are usually the most interesting. A subdomain you don't recognise pointing at a service you no longer use is precisely the kind of forgotten asset this whole exercise is meant to surface.

One more reason for domain owners to run this regularly: the same CT logs that reveal your subdomains also reveal certificates someone else requests for look-alike domains designed to impersonate you. Watching CT is a quiet early-warning system for both your own sprawl and the typosquatting aimed at your brand.

You can't secure what you've forgotten you own. Certificate Transparency is the cheapest way to remember.

Subdomain discovery used to mean noisy brute-force scans and slow wordlists. Now the most complete first pass is a passive query against logs that are public by design. Pull the list, resolve it, and look hard at the names you didn't expect — that's where the work actually is.