Subdomain Enumeration: Techniques and Tools for Security Research (2026)

Most organizations have no complete list of the hostnames they run. A staging box from a project that shipped two years ago, a vendor dashboard nobody decommissioned, a test. host still pointing at a cloud bucket that was deleted last quarter. None of it shows up in the marketing site's navigation, but all of it answers to the same parent domain, and much of it is reachable from the open internet. The forgotten hosts are the ones that go unpatched, and the ones an attacker finds first.

Subdomain enumeration is how you find those hosts before someone else does. It's the practice of discovering the hostnames that sit beneath a registered domain, mail.example.com, api.example.com, vpn-old.example.com, by pulling from public records, resolver data, and the certificate logs that quietly catalogue most of the modern web. For a penetration tester or bug bounty hunter, it's the first real step of reconnaissance and usually the one that decides how much attack surface you actually have to work with. For a defender, it's the only way to inventory assets you don't remember creating.

This guide walks through how subdomain enumeration works in practice: the passive and active techniques that matter, the tools worth installing, and how to turn a messy list of hostnames into something you can actually act on. It assumes you have authorization to test whatever domain you point these methods at, because almost none of this is legal otherwise.

What subdomain enumeration actually is

A domain name like example.com is a single registration, but the organization behind it almost never runs everything on that one name. It splits services across subdomains: a web app on app.example.com, a mail server on mx.example.com, documentation on docs.example.com, internal tooling on hostnames that were never meant to be found at all. Each of these is a DNS name that resolves to an IP address and, often, a running service.

Enumeration is the work of discovering that full list. You start with the registered parent domain and end with an inventory of every hostname beneath it that you can find evidence for. MITRE's ATT&CK framework catalogues this as reconnaissance across two sub-techniques: searching DNS data (T1596.001), which includes "records that outline addressing for a target's subdomains, mail servers, and other hosts," and searching digital certificate data (T1596.003) for an organization's registered name and location. That framing matters because it tells you how defenders think about it. From their side, your enumeration is a recon signature, and the only real mitigation is reducing what's exposed in the first place.

The reason this is worth doing well, rather than running one tool and calling it finished, is coverage. A domain's real footprint is almost always larger than its first page of results. A large organization's subdomains can run well into the thousands, many of them stale, forgotten, or spun up by teams who've since moved on. The host you miss is the one that matters, because it's usually the one nobody's patched.

Passive vs. active enumeration

Every technique falls into one of two buckets, and what separates them is where the data comes from, not how hard the tool works

Passive enumeration gathers subdomains from sources that already hold the information: certificate transparency logs, passive DNS repositories, search engine indexes, threat intelligence feeds. You never send a packet to the target's own infrastructure. That makes passive methods stealthy (the target sees nothing) and fast (you're querying databases rather than waiting on DNS resolution), but it also means you're limited to whatever those third parties already recorded. A subdomain that never got a public certificate and was never caught by a passive DNS sensor simply won't appear.

Active enumeration queries the target directly. You guess hostnames from a wordlist and ask the target's resolvers whether they exist, you attempt a DNS zone transfer, you resolve candidate names against the authoritative nameservers. Active methods find hosts that passive sources never captured, internal naming schemes, hosts behind split-horizon DNS, anything freshly created, but they put queries on the wire that a watchful target can log and attribute to you.

In real engagements you run both, in that order. Passive first, because it's free intelligence that costs the target nothing and hands you a seed list. Active second, to fill the gaps and confirm what's live. The sections below follow that same sequence.

Passive techniques

Certificate Transparency logs

This is the highest-yield passive source available, and it exists because of a browser security policy.

Certificate Transparency is a system of public, append-only logs that record TLS certificates as certificate authorities issue them. It was built so that domain owners and watchdogs could catch mis-issued or unauthorized certificates. The side effect, from a recon perspective, is enormous: every certificate names the hostnames it covers, in its Common Name and its Subject Alternative Name fields, and those names are now permanently public.

What turned CT from a niche feed into a near-complete map of the web was Chrome's enforcement deadline. Since 30 April 2018, Google Chrome requires that all newly issued publicly-trusted TLS certificates be disclosed via Certificate Transparency to be treated as trusted. In practice, that means if an organization put a valid HTTPS certificate on a subdomain after that date, the hostname is almost certainly sitting in a CT log right now. Chrome's own policy documentation is blunt about the consequence: it "does not support any method for hiding domain names or other information within publicly-trusted certificates." For most organizations, that means their subdomains are logged whether they like it or not.

You can query CT logs directly through services like crt.sh, let a tool aggregate them for you, or read the certificate on a known host with an endpoint like the SSL Lookup API to see the Subject Alternative Names it covers. CT has two blind spots worth knowing. First, it only reveals hosts that were given a public certificate, so a subdomain serving plain HTTP or using a certificate from a private CA won't appear. Second, a wildcard certificate (*.internal.example.com) discloses only the wildcard name, not the individual hostnames beneath it, which is one way operators deliberately limit what CT gives away. That's why CT alone is never enough.

MITRE tracks this exact behavior as T1596.003, Digital Certificates, noting that adversaries "search public digital certificate data" for information about a target, including the registered organization's name and location. When you pull subdomains from CT, that's the technique you're executing.

Passive DNS

Passive DNS repositories are databases of historical DNS resolution data, collected by sensors that observe queries and responses across the internet over time. Instead of asking a nameserver what host.example.com resolves to right now, you ask a passive DNS provider what it has ever seen that name resolve to, and what other names shared the same infrastructure.

This is powerful for two reasons. It surfaces subdomains that aren't live anymore but were real at some point, and it's completely invisible to the target, because you're querying a third-party database rather than their servers. MITRE's T1596.001 (DNS/Passive DNS) describes exactly this technique: adversaries "search through centralized repositories of logged DNS query responses (known as passive DNS)," and "may also seek and target DNS misconfigurations/leaks that reveal information about internal networks." The practical upshot is that passive DNS remembers hosts the target has long since taken down, which is often where the interesting attack surface lives. For pivoting on a specific hostname's past records, a dated-snapshot source like the DNS History API serves the same purpose: it shows what a host resolved to over time, not just now.

Search engines and OSINT sources

Search engines index subdomains as a byproduct of crawling. A targeted query (site:example.com -www) returns subdomains Google has already found, and variations across engines, Bing, DuckDuckGo, Yandex, surface different sets because they crawl differently. It's low-effort and worth a pass, though it only catches hosts that have been linked to and crawled.

Beyond search engines, the same passive philosophy extends to any public dataset that happens to record hostnames: internet-wide scan databases, threat intelligence feeds, and large DNS datasets. Most enumeration tools fold dozens of these sources together so you don't have to query each by hand.

Active techniques

DNS brute forcing

When passive sources run dry, you generate candidate hostnames and test them. DNS brute forcing takes a wordlist of common subdomain names (dev, staging, vpn, admin, mail, and thousands more) prepends each to the target domain, and resolves the result. Names that resolve exist; names that don't, don't.

The technique is only as good as three things: your wordlist, your resolver pool, and your wildcard handling. A larger, smarter wordlist finds more hosts. A big list of fast public resolvers lets you run millions of queries without hammering one server. And wildcard filtering (covered below) is what keeps the results honest.

Brute forcing finds what passive methods structurally cannot: hosts that never got a public certificate, never appeared in passive DNS, and were never linked anywhere. The internal-sounding name a team invented last week shows up here or nowhere.

Zone transfer attempts

A DNS zone transfer (AXFR) is the mechanism secondary nameservers use to copy the full contents of a zone from a primary. If a nameserver is misconfigured to allow transfers to anyone who asks, a single request hands you every record in the zone, the complete subdomain list, no guessing required.

RFC 5936, which defines the AXFR protocol, is explicit that this is supposed to be locked down. It dedicates an entire section to authorization and warns that zone contents can be enumerated as a side effect if access isn't restricted. In modern practice, almost every competent operator restricts AXFR to known secondaries, so an open transfer is rare. But it costs one query to check, and when it works, the payoff is the entire zone at once. Always try it; never count on it.

Permutation and alteration scanning

Once you have a confirmed set of subdomains, you can mine them for more. Permutation scanning takes known hostnames and generates variations: if api.example.com and api-dev.example.com both exist, a tool will try api-staging, api-prod, api-test, api-v2, and so on, then resolve each candidate. Organizations name things in patterns, and permutation tooling exploits those patterns to find siblings of hosts you already know about. It's a force multiplier on whatever your passive and brute-force passes turned up.

The wildcard problem

Before you trust a single brute-forced result, you have to deal with wildcard DNS. A wildcard record (*.example.com) resolves every possible subdomain to the same address, which means a naive brute-force run will report thousands of "valid" subdomains that don't actually exist as distinct hosts. asdfqwer.example.com resolves, does-not-exist-12345.example.com resolves, everything resolves, and your results are worthless.

Good tooling detects wildcards by resolving a few deliberately random names first. If garbage names come back with answers, a wildcard is in play, and the tool filters results against that baseline, keeping only hostnames whose answers differ from the wildcard's. If you're building your own pipeline, this is the step that separates a real asset list from a pile of false positives. puredns, for example, exists largely to solve this: it filters wildcards and works around DNS poisoning by validating answers against a set of trusted resolvers.

One more wrinkle worth knowing: DNSSEC's older NSEC records accidentally made zone enumeration trivial, because they let you walk a zone name by name. NSEC3 was introduced (RFC 5155) specifically to make that harder by hashing the names, though the same RFC acknowledges NSEC3 records remain susceptible to offline dictionary attacks against those hashes. Later guidance in RFC 9276 recommends minimal NSEC3 settings and notes that plain NSEC is often preferable. You rarely rely on this as a primary technique, but it's useful to understand why signed zones sometimes leak more than their operators expect.

Tools worth knowing

The ecosystem is mature, and a handful of tools do most of the work. Here's what each is actually for.

If you're wondering how to find subdomains of a domain in practice, it comes down to a short pipeline: subfinder gathers passive candidates, you pipe them into dnsx to resolve and filter, then into httpx to see which hosts respond. ProjectDiscovery's own documentation shows the pattern directly:

subfinder -silent -d example.com | dnsx -silent -a -resp

That one line pulls passive subdomains for the domain, resolves each one, and prints only the names that return an A record, along with the IP. Add httpx on the end and you learn which of those are serving live web content. Swap example.com for a domain you're authorized to test.

Amass is the tool to reach for when you want depth over speed. Its collection engine folds passive sources and active techniques into a single run and stores results in a queryable database, which is what you want when you're mapping a large organization rather than checking one domain. subfinder and the rest of the ProjectDiscovery chain are what you want when speed and composability matter more.

From a list of hostnames to an asset inventory

Finding subdomains is the start. The result that's actually useful is knowing which of them are live, which are dead, and which are dead in a dangerous way.

Once you've resolved and probed your list, three categories emerge. Live hosts that respond are your active attack surface, the things to actually test. Dead names that no longer resolve are mostly noise. And the dangerous middle: hostnames with DNS records that still point at services no longer under the owner's control. That's the setup for subdomain takeover, and it's one of the highest-value findings in the whole process.

OWASP's Web Security Testing Guide covers this as WSTG-CONF-10, Test for Subdomain Takeover. The vulnerability exists when a subdomain's DNS record points at an external service (a cloud bucket, a hosting platform, a SaaS endpoint) that's been deprovisioned, and the provider lets anyone re-register the now-free resource. Claim the resource, and you control content served from the victim's subdomain, which opens the door to phishing with a legitimate hostname, cookie theft, and credential harvesting. OWASP rates an NS-record takeover as the highest-impact variant, since it can hand over the entire DNS zone.

This is where the activity window of a subdomain stops being trivia and becomes the signal. A host that resolved last year but hasn't been seen active recently is exactly the kind of dangling record that takeover hunting targets. Tracking last-seen and inactive-from dates across a domain's subdomains is how you separate "live infrastructure" from "decommissioned but still pointing somewhere," without probing every host yourself. It's the same pivot-on-stale-infrastructure thinking behind How to Investigate a Suspicious IP Address: A Step-by-Step Threat Hunting Playbook, applied to hostnames instead of IPs.

That lifecycle data is the differentiator behind APIFreaks' Subdomain Finder API. Instead of returning a flat list, it returns each subdomain with a first_seen discovery date (where APIFreaks has one on record), a last_seen date, and, for hosts that have stopped resolving, an inactive_from date marking when they went dormant, and it lets you filter by active or inactive status directly. A single call returns one page of that inventory, with total_records telling you the full footprint at a glance:

curl -X GET \
'https://api.apifreaks.com/v1.0/subdomains/lookup?domain=example.com' \
  -H 'X-apiKey: YOUR_API_KEY'

The response below is a real call against example.com, the reserved documentation domain, trimmed to four entries for length. The page itself returns up to 100 records, and example.com's full set runs to 142,269 subdomains across 1,423 pages:

{
  "domain": "example.com",
  "status": true,
  "query_time": "2026-10-09T13:10:49.428292283",
  "current_page": 1,
  "total_pages": 1423,
  "total_records": 142269,
  "subdomains": [
    {
      "subdomain": "vm3409168.example.com",
      "last_seen": "2026-09-28"
    },
    {
      "subdomain": "vm3899785.example.com",
      "last_seen": "2026-09-29"
    },
    {
      "subdomain": "vm1343398.example.com",
      "last_seen": "2025-12-13",
      "inactive_from": "2025-12-13"
    },
    {
      "subdomain": "vm3686192.example.com",
      "last_seen": "2025-11-14",
      "inactive_from": "2025-11-14"
    }
    // ... 96 more records on this page
  ]
}

Reading the fields: the last two entries carry an inactive_from date, meaning they have stopped resolving (the date matches each host's last_seen), while the first two, still resolving, show only a recent last_seen. None of these particular records carry a first_seen date. On a real target you own or are authorized to test, those dormant entries are the ones to check first for a dangling reference. The sheer volume here is its own lesson: example.com is an IANA-reserved domain nobody operates, so the 142,269 mostly vm-prefixed hostnames are passive-DNS noise logged from software that defaults to example.com, a live reminder that raw results need the wildcard and false-positive filtering covered earlier before you trust them. The endpoint also takes optional before and after query parameters to filter results to a date range, and a status query parameter (distinct from the status field in the response body) set to active or inactive, so you can pull just the live infrastructure or just the dormant records in a single call.

For deeper pivoting once you have a target host, the Subdomain Finder API pairs naturally with APIFreaks' other reconnaissance endpoints: the DNS Lookup API to pull live A, MX, NS, and CNAME records for a resolved subdomain, and the Domain WHOIS Lookup API to tie a host back to its registration and ownership data. Where the subdomain lookup tells you what exists, those tell you what each host is and who's behind it.

A quick word on authorization

Subdomain enumeration is legal to perform against your own assets and against targets you have explicit written permission to test, a signed engagement contract, or a bug bounty program's published scope. Passive techniques are a gray area some argue is always fair game since you're only querying public third-party data, but active techniques (brute forcing, zone transfers, probing) send traffic to infrastructure you don't own, and doing that without authorization can cross legal lines depending on jurisdiction. The safe rule: know your scope before you run active tooling, and stay inside it. This guide is written for authorized security research, and that's the only context these methods belong in.

Frequently asked questions

What is subdomain enumeration?

Subdomain enumeration is the process of discovering the hostnames that exist beneath a registered domain, such as mail.example.com or api.example.com. Security researchers use it to map an organization's full attack surface during reconnaissance, pulling candidate hostnames from public records like certificate transparency logs and passive DNS, then confirming which ones are real and live.

What is the difference between passive and active subdomain enumeration?

Passive enumeration gathers subdomains from third-party sources (certificate transparency logs, passive DNS, search engines) without sending any traffic to the target, which makes it stealthy but limited to what those sources already recorded. Active enumeration queries the target directly through DNS brute forcing, zone transfer attempts, and resolution, which finds hosts passive methods miss but generates traffic the target can see and log. Most engagements use passive techniques first, then active ones to fill the gaps.

Why are certificate transparency logs useful for finding subdomains?

Certificate Transparency logs are public, append-only records of the TLS certificates that certificate authorities issue, and each certificate lists the hostnames it covers. Since 30 April 2018, Chrome has required nearly all newly issued public certificates to be disclosed in these logs to be trusted, so any subdomain given a valid HTTPS certificate after that date is almost certainly recorded. That makes CT logs the single highest-yield passive source, though they only reveal hosts that received a public certificate, and a wildcard certificate hides the individual hostnames beneath it.

What are the best subdomain enumeration tools?

OWASP Amass is the standard for in-depth attack-surface mapping, combining dozens of passive sources with active techniques. ProjectDiscovery's subfinder is the fast, go-to tool for passive discovery, and pairs with dnsx for resolution and httpx for probing live hosts. puredns handles fast brute forcing with accurate wildcard filtering, and Gobuster offers DNS and virtual-host brute-force modes. Most workflows chain several of these together rather than relying on one.

Is there a way to find all subdomains of a domain?

There's no single method that guarantees every subdomain, because a hostname that was never given a public certificate, never seen by a passive DNS sensor, and never guessed by a wordlist leaves no public trace. What gets you closest is layering techniques: pull passively from certificate transparency logs, passive DNS, and search engines, then brute-force a wordlist against the domain, run permutation scanning on what you find, and resolve everything while filtering wildcards. Combining sources this way, rather than trusting one tool, is how you build the most complete picture of a domain's subdomains that public data allows.

What is subdomain takeover and how does enumeration relate to it?

Subdomain takeover is a vulnerability where a subdomain's DNS record still points at an external service (like a cloud bucket or hosting platform) that's been deprovisioned, letting an attacker re-register the free resource and serve content from the victim's hostname. OWASP documents it as WSTG-CONF-10. Enumeration relates to it directly: finding dormant or dangling subdomains, hosts that resolved in the past but have gone inactive, is how you identify takeover candidates. Historical activity data like first-seen, last-seen, and inactive-from dates makes those dangling records easy to spot.

Is subdomain enumeration legal?

Performed against your own domains or targets you have explicit written authorization to test (an engagement contract or a bug bounty program's published scope), yes. Passive techniques that query only third-party public data are lower-risk, but active techniques send traffic to infrastructure you don't own, and doing that without permission can violate computer-misuse laws depending on where you are. Always confirm your scope before running active tooling.

Put subdomain enumeration to work

Good subdomain enumeration ends with an inventory you can act on: live hosts to test, dead names to ignore, and dangling records to flag before someone else claims them. The lifecycle data that sorts hosts into those buckets, first-seen discovery dates, last-seen timestamps, inactive-from flags, and activity status, is what the APIFreaks Subdomain Finder API returns in a single call, so you can tell live infrastructure from decommissioned-but-dangling without probing every host by hand.

Start mapping subdomains with 10,000 free credits. The Subdomain Finder API requires no credit card to get started. Create a free account and make your first call in minutes.