Enumerate DNS Records & Subdomains

You’ve mapped the target’s network, scanned open ports, and built a picture of what services are exposed. But there’s a blind spot: the DNS records and subdomains that quietly reveal staging servers, admin panels, and forgotten internal tools. Enumerating DNS records and subdomains is a reconnaissance superpower — it turns a single domain into a treasure map of attack surface. Without it, you’re leaving critical assets undiscovered and your security assessment incomplete.

The Problem This Lesson Solves

Traditional port scanning only sees IP addresses. But modern organizations run dozens, sometimes hundreds, of subdomains — dev.company.com, staging.company.com, jira.company.com, api.company.com — each potentially hosting a different application with its own vulnerabilities. A penetration tester who skips DNS enumeration might completely miss the exposed internal wiki or the outdated test instance with default credentials.

The stakes are high: subdomains often have weaker security than the main site. They're set up quickly, forgotten, and rarely patched. Meanwhile, DNS records themselves leak information — an MX record tells you the mail provider, a TXT record might contain a verification string that reveals third-party services, and an NS record can expose delegation misconfigurations.

DNS enumeration is the systematic process of discovering all DNS records and subdomains associated with a target domain. It's a fundamental phase of reconnaissance — the first step in any ethical hacking engagement — and it directly expands the attack surface you can test.

Core Concept / Mental Model

Think of DNS as the internet's phonebook. When you type example.com, a resolver looks up the IP address through a chain of queries. But the phonebook has many more pages than just the main listing — every subdomain is like a separate extension, and each record type is a different kind of entry.

Here's the key insight: DNS is public by design. Anyone can query it. That's both a feature and a security risk. An attacker (or ethical hacker) can ask the same questions a legitimate user would — but with a different intent.

Let's break down the record types you'll care about:

Subdomain discovery works through two main techniques:

1. Brute-forcing — guessing common names (admin, dev, test, staging) against the domain.
2. Passive enumeration — using search engines, certificate transparency logs, and public databases to find subdomains that already exist.

Pro tip: Think of DNS enumeration as the map phase of recon. Better map means better attack planning — you'll know exactly where to scan next.

How It Works Step by Step

The process breaks down into three phases:

1. Gather baseline records — Start with the domain itself. Query standard record types (A, MX, NS, TXT, SOA) to understand the target's DNS posture.
2. Discover subdomains — Use a combination of brute-forcing and passive sources to find hidden hostnames.
3. Resolve and verify — For each discovered subdomain, resolve its IP address and check for live services. This confirms what's actually reachable and avoids wasting time on dead hosts.

Step 1 – Baseline Records with dig

The dig command is your Swiss Army knife for DNS. It's part of dnsutils (or bind-utils on some Linux distros).

# Install dig on Debian/Ubuntu
dig -v || sudo apt install dnsutils

# Query A records
dig example.com A

# Query all common records at once
dig example.com ANY

# Or use +short for concise output
dig example.com MX +short
dig example.com NS +short

Expected output (simplified):

;; ANSWER SECTION:
example.com.    3600  IN  A  93.184.216.34
example.com.    3600  IN  MX  10 mail.example.com.
example.com.    3600  IN  NS  a.iana-servers.net.

Step 2 – Enumerate Subdomains with dnsrecon

dnsrecon is a powerful tool that performs brute-force, dictionary, and reverse lookup enumeration. It's pre-installed in Kali Linux.

# Install if needed
sudo apt install dnsrecon

# Run a dictionary brute-force with a common wordlist
# -d: domain, -t brt: brute-force, -D: dictionary, -j: JSON output
dnsrecon -d example.com -t brt -D /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -j dnsrecon.json

Expected output (trimmed):

[*] Performing 2560 tests against example.com
[+] Found: www.example.com 93.184.216.34
[+] Found: mail.example.com 93.184.216.5
[+] Found: dev.example.com 93.184.216.99

The JSON output lets you parse results programmatically for further scanning.

Step 3 – Passive Discovery with amass

amass excels at passive enumeration by scraping certificate transparency logs and other public sources. It's slower but uncovers subdomains you'd never guess.

# Install amass (if not present)
sudo apt install amass

# Passive enumeration, output to file
amass enum -passive -d example.com -o amass_results.txt

# Show the results
cat amass_results.txt

Expected output (line-delimited):

api.example.com
staging.example.com
admin.example.com
old-blog.example.com

Step 4 – Verify with host or nslookup

For each subdomain you find, you need to confirm it's live. A quick loop with host does the job:

# Loop through discovered subdomains and resolve them
while read sub; do
  ip=$(host "$sub.example.com" | grep 'has address' | awk '{print $NF}')
  if [ -n "$ip" ]; then
    echo "$sub.example.com -> $ip"
  fi
done < subdomains.txt

Expected output:

api.example.com -> 93.184.216.34
staging.example.com -> 93.184.216.77

Now you have a verified list of live subdomains to feed into your port scanner for the next phase.

Pro tip: Always combine brute-force and passive methods — they find different sets of subdomains, and the overlap is often smaller than you'd think.

Compare Options / When to Choose What

Different tools shine in different scenarios. Here's a quick comparison:

When to choose what?

• Start with dig for baseline records — it's quick and gives you control.
• Use dnsrecon when you have a wordlist and want comprehensive brute-force.
• Pick amass when the target is large and you want to maximize passive discovery without aggressive queries that might alert the target.
• Use subfinder if you need a fast passive scan for a quick engagement.

Variations

• Wordlists matter — The quality of your brute-force depends on the wordlist. SecLists and danielmiessler.com wordlists are industry standards.
• Automated pipelines — Tools like aquatone can take your subdomain list, screenshot live sites, and produce a visual map of the attack surface.
• APIs — Services like crt.sh (certificate transparency) and VirusTotal offer free APIs you can query with curl to find subdomains without installing heavy tools.

Troubleshooting & Edge Cases

DNS over HTTPS (DoH) blocks traditional queries

Some networks or VPNs force DNS traffic through HTTPS, breaking dig and dnsrecon. Fix: use dig @1.1.1.1 to target a public resolver directly, or use curl to query a DoH API.

# Query DoH manually with curl
curl "https://dns.google/resolve?name=example.com&type=A"

Wildcard DNS entries

A target with *.example.com returns an IP for any subdomain — including ones that don't exist. This inflates your results and wastes time.

Symptom: Every guessed subdomain resolves to the same IP. Fix: Compare the IP of a random nonsense host and filter out matches.

# Get the wildcard IP
random_ip=$(host asdf1234.example.com | grep 'has address' | awk '{print $NF}')

# Filter your list with awk
awk -v bad="$random_ip" '!($0 ~ bad)' subdomains.txt

Rate limiting and WAFs

Aggressive brute-forcing can trigger rate limits or WAF protections, slowing you down or blocking your IP.

Symptom: Queries timeout or receive SERVFAIL. Fix: Increase delays with -t brt -D ... -j out.json and use -l 2 in dnsrecon to limit queries per second, or switch to passive tools like amass.

Subdomain takeover opportunities

Some subdomains point to deprovisioned cloud services (e.g., a dangling CNAME to S3 bucket that no longer exists). These are high-value vulnerabilities — you can claim the resource and take over the subdomain.

Check: For each CNAME, verify the target resource exists. Tools like subjack or can-i-take-over-xyz lists automate this.

Pro tip: Always document your findings in a structured file (JSON/CSV) — you'll need the data for the exploitation phases.

What You Learned & What's Next

You now understand why enumerating DNS records and subdomains is the backbone of reconnaissance. You can:

• Use dig to pull baseline records (A, MX, NS, TXT) and interpret their security impact.
• Run dnsrecon for brute-force subdomain discovery and amass for passive OSINT gathering.
• Verify discovered subdomains and handle common pitfalls like wildcards and DoH.
• Choose the right tool per scenario, from quick checks to large-scale engagements.

These skills directly feed into the next step in your ethical hacking path: scanning the discovered subdomains for open ports and vulnerabilities. With your DNS map in hand, you're ready to probe the services you just uncovered — and that's where the real exploitation begins.

Keep practicing: combine dnsrecon and amass on a target you own (like hackertarget.com) and document every record you find. Then move forward to service enumeration.