dnsmap: A Focused Subdomain Brute-Forcing Tool for DNS Recon

Sometimes you don’t need a Swiss army knife — you need a tool that does exactly one thing reliably. That’s dnsmap. It’s a straightforward, no-frills subdomain brute-forcing tool, originally built with penetration testing in mind, and it’s stuck around because its simplicity makes it fast and predictable to use as part of a bigger recon workflow.

dnsmap was created specifically to help testers discover subdomains during the information-gathering phase of an engagement, particularly ones that might reveal internal infrastructure names, forgotten staging environments, or naming conventions an organization uses internally.

How dnsmap Works

The mechanics are simple and that’s the point:

1. dnsmap takes a target domain and a wordlist (it ships with a built-in list of common subdomain names, or you can supply your own).
2. For each word in the list, it constructs a candidate subdomain (word.targetdomain.com) and performs a DNS resolution.
3. If the subdomain resolves to an IP address, it’s recorded as a discovered host along with its resolved address.
4. Results are printed to the console and can optionally be saved in both a CSV-style and human-readable format.

There’s no zone transfer testing, no reverse lookups, no SRV record checks — dnsmap sticks purely to brute-force subdomain discovery, which makes it lightweight and fast to run as an early step before switching to heavier tools.

Installation

Kali Linux includes dnsmap by default. Manual installation:

sudo apt update
sudo apt install dnsmap -y

From source:

git clone https://github.com/makefu/dnsmap.git
cd dnsmap
make
sudo make install

Verify:

dnsmap --help

Basic Syntax

dnsmap <domain> [options]

Core Command Examples

Basic scan using the built-in wordlist:

dnsmap example.com

Output:

dnsmap 0.36 - DNS Network Mapper

[+] searching (sub)domains for example.com using built-in wordlist
[+] using maximum random delay of 10 ms between requests

www.example.com
IP address #1: 93.184.216.34

mail.example.com
IP address #1: 93.184.216.36

[+] 2 (sub)domains and 2 IP address(es) found

Using a custom wordlist:

dnsmap example.com -w /usr/share/wordlists/subdomains-top1million-5000.txt

Saving results to a CSV-style file for reporting:

dnsmap example.com -c dnsmap_results.csv

Saving both regular and CSV results together:

dnsmap example.com -r dnsmap_results.txt -c dnsmap_results.csv

Adjusting the random delay between DNS requests (to be gentler on the target):

dnsmap example.com -d 200

This sets a maximum random delay of 200 milliseconds between lookups, reducing the chance of tripping rate limits or looking like an automated flood to a monitoring system.

Specifying a custom IP to ignore (useful when a domain has a wildcard record you want to filter out):

dnsmap example.com -i 93.184.216.100

Any subdomain that resolves to this ignored IP is treated as a false positive from wildcard DNS, rather than a genuine discovery.

Configuration Options Worth Knowing

• -w — supplies a custom wordlist file instead of the built-in one.
• -r — saves results in a regular, human-readable text file.
• -c — saves results in CSV format for spreadsheet import or reporting automation.
• -d — sets the maximum random delay (in milliseconds) between requests, useful for reducing noise on sensitive networks.
• -i — provides an IP address to ignore, critical for filtering out wildcard DNS false positives.

Real-World Use Cases

1. Fast first-pass subdomain discovery. When time is limited early in an engagement, dnsmap’s simplicity and speed make it a good first pass before switching to more comprehensive (and slower) tools.

2. Supplementing certificate-transparency-based recon. CT logs only reveal subdomains that had a TLS certificate issued. dnsmap’s brute-force approach catches internal-only or non-HTTPS subdomains that would never show up in a CT log search.

3. Building internal naming convention profiles. Discovering a pattern like dev1.example.com, dev2.example.com, stage1.example.com during an authorized assessment often reveals an organization’s naming conventions, which can guide further targeted guessing.

4. Lightweight periodic monitoring. For an organization tracking its own external subdomain footprint over time (attack surface management), a scheduled dnsmap run against a wordlist of expected naming patterns is a simple, low-overhead check for new or forgotten subdomains appearing unexpectedly.

Workflow and Tool Integration

A typical use in a broader recon chain:

# Step 1: Quick first-pass brute-force with dnsmap
dnsmap example.com -c dnsmap_results.csv

# Step 2: Deeper enumeration with DNSRecon for zone transfer and SRV checks
dnsrecon -d example.com -t axfr,srv

# Step 3: Merge subdomain lists and confirm live hosts
awk -F, '{print $1}' dnsmap_results.csv | sort -u | httpx -silent -o live_hosts.txt

# Step 4: Feed into Nmap/Nikto for deeper testing

dnsmap’s speed makes it well suited to being the very first tool in a chain, quickly narrowing down what’s worth spending more time on with heavier tools like DNSRecon or Amass.

Performance Optimization

• Use the built-in wordlist for a fast initial pass, then follow up with a larger custom wordlist only if the target looks interesting enough to warrant deeper enumeration.
• Adjust -d (delay) based on how sensitive the target network is — a financial or government target may warrant a higher delay to stay well under any rate-limiting thresholds.
• Since dnsmap is single-threaded by design in most builds, don’t expect it to compete on raw speed with more modern, concurrent tools for very large wordlists — that’s a reasonable tradeoff for its simplicity.

Troubleshooting

• If almost every subdomain in your list resolves successfully, you’re very likely dealing with a wildcard DNS record — use -i to filter out the wildcard’s IP and re-run.
• No results at all despite a large wordlist can mean the resolver you’re using is blocking or rate-limiting rapid queries — try a different resolver or increase -d.
• If the built-in wordlist feels outdated, supply a current one via -w; SecLists’ subdomain wordlists are commonly used replacements.

Common Mistakes

• Not checking for wildcard DNS before trusting results, leading to a list full of false positives.
• Running dnsmap with an extremely large wordlist and no delay against a small target, which can look like a DNS-based denial-of-service attempt.
• Treating dnsmap’s results as a complete subdomain inventory — it only finds what’s in your wordlist, so combining it with certificate-transparency tools is essential for full coverage.

Best Practices

• Always run a wildcard DNS check first (query a random, almost-certainly-nonexistent subdomain) before trusting bulk results.
• Combine dnsmap with certificate transparency tools like crt.sh lookups or subfinder for more complete coverage.
• Keep delay settings reasonable on sensitive or production networks to avoid unintentional denial-of-service effects.

Mini Lab Example

Against a lab domain with a few manually configured subdomains in /etc/hosts or a local BIND zone:

dnsmap lab.local -w custom_wordlist.txt -r dnsmap_lab_results.txt

Where custom_wordlist.txt contains a handful of test names matching your lab’s configured records (e.g., www, dev, test). You should see each resolvable name listed along with its IP in the saved results file.

FAQ

Is dnsmap still useful compared to newer tools like Amass or Subfinder? Yes, particularly as a fast, low-dependency first pass, or in environments without internet access to certificate transparency logs (like isolated internal assessments).

Does dnsmap require root privileges? No, it performs standard DNS resolution, which doesn’t need elevated permissions.

Can dnsmap detect zone transfer vulnerabilities? No — that’s outside its scope. Use DNSRecon or Fierce for zone transfer testing.

How do I avoid false positives from wildcard domains? Query an obviously nonexistent subdomain first (like a random string), and if it resolves, use the -i flag to filter out that IP from your dnsmap results.

Summary

dnsmap won’t replace a full DNS reconnaissance suite, but it doesn’t try to. As a fast, dependable subdomain brute-forcer, it’s a solid first step in any authorized recon workflow, especially when paired with certificate-transparency-based tools and a more comprehensive scanner like DNSRecon for the deeper checks.

References

• GitHub repository: https://github.com/makefu/dnsmap
• Kali Linux tool page: https://www.kali.org/tools/dnsmap/