What a subdomain lookup can actually see
There is no query that asks a domain for its subdomains. DNS answers questions about names you already know: ask for the address of api.example.com and you get one, ask what names exist under example.com and there is no such question to ask. Zone transfers used to answer it and are refused by every nameserver worth running.
So every subdomain finder works the same way: it collects names that were published somewhere else and indexes them. The largest such source is certificate transparency — since 2018, browsers reject a certificate that was not logged in a public append-only log, and every certificate carries the hostnames it covers. A staging box that was given HTTPS is a hostname in a public log, permanently.
example.com → api.example.com, staging.example.com, vpn.example.com …
That is the trade this tool makes. It is passive: nothing is probed, no DNS request is made on your behalf, and the domain you name is never contacted. What comes back is what was published, which is not the same as what exists.
Where the names come from
The index is crt.name, a free public service that reads every usable certificate transparency log in Chrome's and Apple's programs as entries land, pulls the hostnames out of each certificate, and throws the rest away. Retired logs are replayed from the Internet Archive, and names are added from Common Crawl, ICANN CZDS zone files, ProjectDiscovery Chaos and HaGeZi blocklists.
Two consequences worth holding on to. A name in this list was published once — it may have been decommissioned years ago and it may not resolve today. And a name that is missing is not proof of absence: a subdomain that never got a public certificate and never appeared in a crawl or a zone file is invisible here.
The index never deletes a name, so this is closer to a history than a snapshot. That is exactly what makes it useful for finding the forgotten staging server, and exactly why it should not be read as an inventory of what is live.
Reading the result
Four numbers sit above the table, and each one answers a different question.
| Figure | What it means |
|---|---|
| Names | How many distinct names the index holds for this domain, after duplicates are collapsed. The domain itself counts as one when the index has a row for it. |
| New in 30 days | How many were first seen inside the last thirty days. A jump here usually means a certificate was reissued across a range of hosts, or something new was deployed. |
| Deepest level | How many labels the longest name has below the domain. api.example.com is level 1; api.staging.example.com is level 2. Deep nesting is often a sign of per-environment or per-tenant hostnames. |
| With a date | How many carry a first-seen date at all. Names that arrived through a source with no date are listed with an unknown date rather than being given a made-up one. |
The controls
| Control | What it does | Reach for it when |
|---|---|---|
| Domain | Names the domain to look up. A subdomain or a full URL is widened to its registrable domain, and the result says so. | Always. It is the only input the lookup takes. |
| Filter | Keeps names containing what you type, matched anywhere in the name and ignoring case. It searches the whole result, not the page on screen. | The list is long and you are looking for a pattern — staging, vpn, an internal product name. |
| Order | Reorders the whole result. Tree order compares labels right to left; the two date orders put undated names last. | Tree order to read the shape of the estate, newest first to see what changed. |
| Copy and download | Takes every name matching the current filter, in the current order. Plain text is one name per line; CSV adds the level and the date; JSON adds the domain, the time of the lookup, and whether the answer was complete. | Feeding the list into something else. Plain text pipes straight into a resolver or a scanner. |
- Tree orderCompares labels right to left, so every name under one branch sits together.
- AlphabeticalPlain A to Z on the whole name, which splits branches apart.
- Newest firstMost recently seen first. Undated names go last.
- Oldest firstLongest on file first. Undated names go last.
- Deepest firstMost labels first, which surfaces the deeply nested names.
Two interactions worth knowing. The filter and the order are applied before the export, so what you save is what you are looking at — clear the filter first if you want everything. And paging is only a rendering decision: it never affects the filter, the order, the counts above the table, or what a download contains.
Limits, and why each one is there
The index is free, unauthenticated, and meters by address — and the address it sees is this site's, shared by everyone using this page. Most of what follows exists so that one visitor cannot spend the day's allowance for everybody.
| Limit | Value | Why |
|---|---|---|
| Lookups per visitor | 20 / hour | Generous for a person, and far below the site ceiling, so one caller cannot take the tool away from everyone else. |
| Lookups per hour, site-wide | 40 / hour | The number that keeps this site inside the upstream's free tier: this an hour is under a thousand a day, which is what the index allows. |
| Response read | 4 MB | Enforced while the reply streams rather than after it lands, so an answer nobody predicted cannot exhaust the server's memory. |
| Names kept | 20,000 | Bounds what crosses into your browser. When it bites, the result says how many the index held rather than quietly showing a prefix. |
| Rows per page | 100 | Rendering twenty thousand table rows freezes a phone. Nothing is dropped — the filter and every download still reach the whole list. |
The very largest domains are refused by the index itself, before any of this applies. Ask it about google.com and it answers that the domain has too many records to serve; there is nothing this tool can do about that except tell you plainly.
What people use it for
Knowing your own attack surface. The honest first step in securing an estate is finding out what is on the internet with your name on it — and it is nearly always more than the list somebody keeps.
Finding the forgotten box. A staging environment from a project that shipped two years ago is still resolving, still running the framework version it was deployed with, and is in nobody's inventory. Certificate transparency remembers it.
Due diligence. Before an acquisition or a security review, the subdomain list is the cheapest available picture of what a company actually runs.
Checking a migration. After moving to a new provider, the names that still point at the old one are the ones nobody remembered to update.
Authorised testing. Scope for a bug bounty is usually written as a domain and its subdomains, and this is how you find out what that covers.