DNS reconnaissance: a practical checklist for subdomain discovery

DNS is still the cheapest way to widen a scope. Before a single packet goes to a web server, the domain's records tell you which providers it depends on, which mail and verification services are trusted to send as it, and — with luck — which forgotten environments are still live. The problem is that DNS recon is easy to run and hard to do completely, so most passes return a confident-looking list that is missing half the surface. This is the checklist we use.

Step 1 — Read the apex records first

Start with the records that exist on the domain itself. They cost one query each and they frame everything afterwards.

dig +short NS    example.com
dig +short SOA   example.com
dig +short MX    example.com
dig +short TXT   example.com
dig +short CAA   example.com
dig example.com ANY

TXT records are the most underrated of the set. They routinely reveal staging providers, ownership of adjacent domains, and mail infrastructure nobody remembered buying.

Step 2 — Attempt a zone transfer

Zone transfers should be refused. When one is not, you get the whole namespace in a single answer, so it is always worth the attempt:

for ns in $(dig +short NS example.com); do
  echo "== $ns"; dig AXFR example.com @$ns +noall +answer
done

Two notes. First, a refused transfer is the normal, correct result — do not report it as evidence of anything. Second, some providers rate-limit AXFR attempts aggressively; if you see timeouts rather than refusals, stop rather than hammer the nameserver.

Step 3 — Passive sources, with realistic expectations

Certificate transparency is the best public source of subdomain names, because every certificate issued for the domain is logged whether or not the host was meant to be public. Beyond that, the free aggregators vary wildly. The important thing is to understand that a source returning nothing is not evidence that nothing exists.

• crt.sh — certificate transparency search. Broad, occasionally slow, worth retrying.
• hackertarget and rapiddns — fast, keyless, and in our testing the most reliable of the free passive APIs.
• Amass passive mode — unions several sources; treat each source's contribution separately so you can tell which one actually answered.
• theHarvester — built for emails and hosts rather than DNS, but useful for the same pass.

Step 4 — Brute force, but handle wildcards

Wordlist brute forcing still finds hosts that no certificate ever recorded. Two things make the difference between a usable result and noise.

Wildcard detection. If the zone answers any name with an A record, every random name in your wordlist will "resolve". Check first by resolving a random string that is definitely not in the zone; if it answers, either drop the wildcard addresses from the result set or stop using that resolver.

Wordlist fit. A DNS brute force wants a subdomain list — prefixes like www, api, staging, vpn — not an alphabetised web-directory list. Feeding an Apache directory list to a DNS scan produces almost nothing, and the usual conclusion ("the domain has no subdomains") is wrong.

gobuster dns --domain example.com \
  -w subdomains-top1million-5000.txt -t 20

Step 5 — Resolve and classify what you found

A list of names is not an inventory. For each one, resolve IPv4 and IPv6, follow the CNAME chain, and record what it points at.

• CNAME chains that end nowhere. A CNAME pointing at a deprovisioned cloud resource is a subdomain-takeover candidate. Capture the terminal target while the chain is still resolvable.
• Shared versus dedicated addresses. Many hosts on one address usually means shared hosting; a dedicated address with one host is more interesting.
• AAAA records. IPv6 hosts are commonly missed by scans that only check A records, and are just as reachable.
• Certificate SANs. A certificate for a host you have not found often lists its siblings. Re-query certificate transparency by hostname, not just by domain.

Step 6 — Record how you got the answer

Every scan you intend to report on should carry: the timestamp, the resolver used, the source list, the wordlist (with a checksum if it is custom), and the raw output. Without those, a "we found 40 subdomains" claim cannot be reproduced, and the client has no way to distinguish your scan from somebody else's old screenshot.

Common mistakes, in order of frequency

1. No wildcard check, so the result set is thousands of identical addresses.
2. Only querying A records, so IPv6-only hosts stay invisible.
3. Trusting a single passive source, or failing to notice that source returned an error.
4. Ignoring TXT records, which would have shown the third-party mail and verification services.
5. Using the wrong wordlist for DNS enumeration.
6. Not re-running later. New hosts appear after deployments; a recon pass is a snapshot, not a fact.

Try it without installing anything

Our public sandbox runs exactly this pipeline — apex records, zone-transfer attempt, passive discovery and resolution — against a domain you choose, and streams the raw command output plus the parsed records. It is two scans per visitor per day, no account, and it only accepts domains you can reasonably test. It is the fastest way to see what the checklist above produces on a real zone.