Subdomain Lookup

DNS answers questions about names you already know. There is a query for “what is the address of mail.example.com” and no query at all for “what names exist under example.com”. That is not an oversight in a protocol that could be extended; it is how the lookup model works, and it is why subdomain discovery is always indirect.

The one bulk mechanism in the protocol is a zone transfer, AXFR (RFC 5936), which hands over the entire zone at once. Operators restrict it to their own secondary servers. That restriction is operational convention rather than an RFC mandate — the standard describes the mechanism, not a duty to refuse it — but it is close to universal in practice, so an open AXFR is a misconfiguration you occasionally find rather than a route you can rely on.

The DNSSEC side effect: zone walking

Signing a zone introduces a second, accidental route. NSEC records prove that a name does not exist by naming the next name that does, which chains every existing name in order and lets anyone walk the chain end to end (RFC 4034, RFC 4035; the problem is stated in RFC 5155 §1). NSEC3 (RFC 5155) replaces those names with hashes to make walking expensive rather than free, and RFC 9276 now recommends zero extra iterations and an empty salt, on the grounds that extra iterations cost the server CPU without stopping offline guessing. The honest summary is that NSEC3 raises the cost of enumeration and does not prevent it for names that are guessable. Our DNSSEC validator shows which of the two a signed zone is using.

Certificate Transparency logs are public, append-only records of issued certificates and precertificates (RFC 6962; version 2 is RFC 9162). What makes them useful for discovery is not the RFC but browser root-program policy: Chrome has enforced CT since April 2018, which makes logging effectively mandatory for any publicly trusted TLS certificate. Each hostname listed in a logged certificate’s subject alternative names becomes publicly searchable.

This tool searches those logs through crt.sh, a search index over the public CT logs operated by Sectigo. That is its primary source. Where a Cert Spotter API key is configured, a crt.sh query that fails falls back to SSLMate’s Cert Spotter, a second index over the same public logs. Both are Certificate Transparency indexes: the tool does no probing of the domain itself and consults no other kind of dataset.

What CT cannot see

• Hosts covered by a wildcard certificate. A certificate for *.example.com reveals the wildcard and nothing about which names actually exist beneath it.
• Hosts served by a private or internal CA. The root-program policy that drives logging covers publicly trusted certificates, so a certificate from a private or internal CA need not appear in CT at all.
• Hosts with no TLS certificate at all. No certificate, no log entry, no result.

The gaps run the other way too. A logged name may not resolve today: CT is a history of what was certified, not a live inventory of what is running. Where CT stops, other approaches begin — passive DNS datasets recording observed resolutions, search-engine indexes, and wordlist brute-forcing of candidate names — each with its own blind spots, and none of them consulted here.

What happens when the index is down

A lookup waits up to 15 seconds for crt.sh and does not retry. That matters because crt.sh is a free public service and is at times unavailable, having been observed returning errors intermittently for hours at a stretch. Where a Cert Spotter API key is configured, a failed crt.sh query falls back to Cert Spotter and the result says which index answered; a result is never assembled from both, and a crt.sh answer is used as-is even when it found nothing. Without that key, crt.sh is the only source and its outage is an outage here for every uncached domain. Successful results are cached for one hour, so a repeat lookup of a domain someone has recently checked can succeed while a fresh one does not. Treat an error here as a statement about the upstream index rather than about your domain.

Each row is a distinct name, with the issuer and the validity dates of the first certificate that introduced it. A few things about how that list is built are worth knowing before you act on it.

Duplicates are collapsed, so counts are names and not certificates

Raw CT data repeats itself heavily: a precertificate and the final certificate can both appear, submissions go to several logs, and a name is re-certified at every renewal. Names are deduplicated here, keeping the first entry seen for each, so the total is a count of distinct names. The issuer and dates shown belong to that first entry and are not necessarily the certificate in use today.

Wildcards appear without their star, and the apex is included

A logged *.example.com is listed as example.com, because the leading *. is stripped before deduplication. The apex itself is kept rather than filtered out, so seeing the bare domain in the list tells you a certificate covered either it or a wildcard beneath it — not that a host called that exists separately.

Expired certificates are not filtered out

Nothing in a crt.sh result is dropped for having expired, and nothing is checked against DNS. A name whose certificate lapsed in 2019 appears exactly like one renewed last week; the Valid To column is what distinguishes them. The Cert Spotter fallback is the exception: it returns unexpired issuances only, so a result it produced is missing names whose last certificate has expired. That is a feature for an audit — old staging and mail names are precisely what you are looking for — and a trap if you read the list as an inventory of live hosts. Confirm anything you intend to act on with an actual lookup: the DNS flattener will show you what a name’s CNAME chain resolves to today, if anything.

The reason to enumerate your own subdomains is that you almost certainly have more of them than you remember, and forgotten ones fail in a specific and exploitable way. A dangling DNS entry is a CNAME still pointing at a cloud resource that has since been deprovisioned. The name resolves, the resource is gone, and whoever re-registers that resource name at the provider can serve content on your subdomain — a subdomain takeover. Microsoft documents the pattern and its prevention in “Prevent dangling DNS entries and avoid subdomain takeover”, and the AWS Security Blog covers the same ground in “Threat tactic spotlight: Subdomain takeover”.

The practical workflow is to take the names this tool returns, resolve each one, and look for CNAMEs whose targets no longer exist or belong to a service you have stopped using. Whatever you find, the remedy is the same and it is at the DNS layer: remove the record when the resource is gone, and remove it before you deprovision the resource rather than after.

A consequence worth knowing about wildcards

Because CT publishes the names on each certificate, using a wildcard certificate keeps the individual hostnames beneath it out of the logs entirely. That is a consequence of how CT works rather than a technique this page recommends: it hides those names from you and from your own audits just as effectively as from anyone else, and it does nothing to make them harder to reach.

Passive lookups versus active probing

Reading public CT data is passive: the query goes to a public index, and no traffic reaches the domain being looked up or any host under it. Actively probing hosts you do not own is a different activity and needs authorisation from the owner. The distinction is worth keeping clear in your own head before a lookup turns into a scan.