Subdomain enumeration: a defensive guide to your own estate

Subdomain enumeration is the process of discovering all the hostnames that exist under a domain — api.example.com, staging.example.com, vpn.example.com, and the dozens you have forgotten about. It is the first move in almost every external attack, and for exactly that reason it should be the first move in your own defence. The principle is simple: you cannot protect what you cannot see, and attackers will enumerate your estate whether or not you do. Mapping your own subdomains first means you find the forgotten admin panel, the dangling CNAME and the expired-certificate host before someone hostile does.

This is a defensive guide. Everything here is framed around enumerating domains you own and are responsible for.

Why enumerate your own estate

Most teams can list their important hostnames from memory. The problem is never the hostnames you remember — it is the ones you do not:

• The demo environment a developer spun up for a sales call two years ago.
• The marketing landing page on a SaaS builder, pointed at by a CNAME nobody removed.
• The internal tool exposed "temporarily" to the internet that never got pulled back.
• The acquired company's domains that were merged in but never inventoried.

Each of these is a live attack surface running software nobody is patching. Enumeration turns "we think we know what we expose" into "here is the actual list", and that list is the foundation of every other security control — expiry monitoring, takeover detection, CVE scanning. Without it, those controls are guarding only the assets you happened to remember.

Passive enumeration: ask the data that already exists

Passive enumeration discovers subdomains without sending any traffic to the target's infrastructure. It reads third-party datasets that already know about your hostnames. For defending your own estate it is the place to start — it is comprehensive, low-effort, and surfaces history your live DNS has forgotten.

The sources that matter:

• Certificate transparency logs. Every publicly trusted certificate lists the hostnames it covers, in a permanent public ledger. This is the single richest passive source — it routinely reveals hosts missing from current DNS.
• Passive DNS. Datasets of DNS resolutions observed across the internet over time, including names that no longer resolve.
• Search engines and public records. Indexed pages, code repositories and config files that reference internal hostnames.
• Your own authoritative data. Zone exports from every DNS provider you use — the ground truth for what you intend to publish.

A flavour of passive enumeration against CT data:

# Pull every certificated hostname under your domain from CT logs
$ curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
    | jq -r '.[].name_value' | tr ',' '\n' | sed 's/^\*\.//' | sort -u

The most valuable output is the diff: hostnames that appear in CT or passive DNS but are absent from your current zone files. Those are the forgotten assets.

Active enumeration: confirm what is live

Active enumeration sends queries to confirm which candidate names actually resolve and respond. On your own estate this is entirely appropriate — you are checking your own infrastructure. The two main techniques:

• DNS resolution of candidate names. Take the passive list (plus a wordlist of common prefixes) and resolve each one to see what is live.
• DNS zone transfer, where a misconfigured nameserver will hand over the entire zone. On your own infrastructure this is a quick completeness check; a successful transfer against a production nameserver is itself a finding to fix.

# Resolve a candidate and see where it points
$ dig +short staging.example.com
203.0.113.45

# Attempt a zone transfer against your own nameserver (should usually fail)
$ dig AXFR example.com @ns1.example.com
; Transfer failed.

Active methods confirm and enrich the passive list — turning "this name was certificated once" into "this name resolves to this IP and responds on these ports". That enrichment is what lets you reason about risk.

Passive vs active at a glance

The right approach combines them: passive to discover the full set of names that have ever existed, active to determine which are live today and what they expose.

Turn the list into an inventory you maintain

Enumeration is not a one-off. New subdomains appear every time someone ships, and a list from last quarter is already wrong. The durable practice is to re-enumerate on a schedule, diff against the previous run, and alert on changes — a new host you did not expect, or an old one whose target has started to dangle.

A pragmatic loop:

1. Passively enumerate from CT logs, passive DNS and your zone exports.
2. Actively resolve the candidates to find what is live.
3. Reconcile against your known-good inventory; investigate anything unrecognised.
4. Feed the live hosts into your other checks — expiry, takeover risk, exposed services, CVEs.
5. Re-run continuously and alert only on what changed.

DomainOps runs this loop for you across your own domains — passive discovery from CT logs and passive DNS, resolution checks to confirm what is live, and continuous alerting when the inventory changes. The exposure-monitoring docs describe the data sources and detections in detail. To see your exposed subdomains for a single domain immediately, try the free subdomain takeover scanner; when you are ready to keep a whole estate mapped continuously, get started here.