Find Subdomains of a Domain

How to find subdomains of a domain

There is no query that returns them all. DNS was never designed to enumerate a zone: the one operation that would do it, a zone transfer (AXFR), is refused by essentially every authoritative nameserver on the public internet. So every subdomain finder, including this one, is reading public records and guessing at the rest. Treat any result you get as a floor, never a ceiling.

Three approaches exist. Two of them work, and they fail in opposite directions:

We run the first two together and merge the results, which is why the tool reports which source each name came from.

Why certificate transparency finds more than a wordlist

Certificate transparency logs are append-only public ledgers. Since 2018 Chrome has refused to trust a certificate that was not logged, so in practice every CA publishes every certificate it issues, and every hostname on that certificate goes into the ledger along with it.

The consequence is the useful part: a hostname that held a public certificate for a single hour in 2019 is still in the log today. A wordlist can only see what is live; CT sees what was ever live. On most real domains it returns several times as many names.

The blind spot is the wildcard certificate. A cert for *.example.com covers api.example.com, staging.example.com and every other first-level name while logging exactly one entry: *.example.com. An organisation that issues one wildcard per environment is close to invisible to CT-based discovery. If a scan of a large domain comes back suspiciously short, a wildcard is usually why.

The results that do not resolve are the interesting ones

Because CT is append-only, a scan routinely returns hostnames with no A record behind them. That is not noise. A name that still has a CNAME pointing at a deprovisioned S3 bucket, Heroku app or Netlify site is a dangling DNS record, and anyone who claims that resource on the provider serves content on your hostname. That is subdomain takeover, and it is the single most common finding in this kind of scan.

The check is quick: for anything in the results that returns no IP, run the hostname through the DNS Record Lookup. A CNAME pointing somewhere that answers with a "no such app" or "bucket does not exist" page is a live takeover risk. No CNAME and no A record is just a stale log entry.

If you run a SaaS, your customer list is in the CT logs

This cuts both ways, and most teams shipping multi-tenant custom domains never think about it. Every time you issue a certificate for a customer hostname, that hostname is published to a public ledger within minutes. Anyone can watch the feed. If your customers are on acme.yourapp.com, your entire tenant list is enumerable by anyone who runs this tool against your domain, and if they bring their own domains, the certificate still ties their domain to your platform.

There is no way to opt out: CT logging is a condition of the certificate being trusted at all. What you can control is what the hostname leaks. Tenant slugs derived from a company name publish your customer roster; opaque per-tenant identifiers do not.

Domainee is a custom domains API for SaaS with a native MCP server, 50 domains and 100 GB free. If you are handing customers a hostname today, the Next.js multi-tenant guide covers the routing and certificate side of it end to end.

Doing this from the command line

The same enumeration is available as a keyless endpoint, so you can put it in a script without an API key or a signup:

curl -s "https://api.domainee.dev/v1/tools/subdomain-finder?domain=example.com" | jq

It returns a deduplicated, sorted list with a source field. Rate limits are per IP and there is no uptime commitment, so it suits scripts and one-off audits rather than a production dependency.