Puredns: Building Accurate Subdomain Enumeration on Top of MassDNS’s Speed
Hook
Public DNS resolvers can answer millions of queries per minute, but they’ll lie to you about half the results. Wildcard DNS records and poisoned responses turn raw MassDNS output into a minefield of false positives that waste hours of manual cleanup.
Context
Subdomain enumeration is the foundation of reconnaissance in bug bounty hunting and penetration testing. Tools like MassDNS revolutionized this space by leveraging public DNS resolvers to perform bulk lookups at unprecedented speeds—resolving millions of domains in minutes instead of hours. But speed came with a cost: garbage results.
The problem isn’t MassDNS itself. It’s the infrastructure it relies on. Public DNS resolvers are unreliable by nature. Some return poisoned answers for censorship or ad injection. Others sit behind wildcard DNS configurations that resolve every possible subdomain to the same IP address, generating thousands of false positives. Before puredns, security researchers had to choose between speed (using MassDNS with messy results) or accuracy (using slower, more conservative tools). They needed both.
Technical Insight
Puredns is architecturally a three-phase pipeline that wraps MassDNS with intelligence layers. Written in Go, it orchestrates bulk resolution, wildcard detection, and validation as separate stages that each solve a specific reliability problem.
The first phase delegates to MassDNS for raw speed. You provide a wordlist and root domains, and puredns generates permutations, then hands them to MassDNS with a list of public resolvers. This is where you get the performance advantage—MassDNS’s stub resolver can saturate network bandwidth and process queries faster than traditional recursive resolvers. But the output is polluted.
The second phase is where puredns earns its name: wildcard detection. This is the algorithmic core. When a domain like *.example.com resolves to the same IP for any subdomain, the tool filters wildcards based on DNS answers obtained from trusted resolvers (defaulting to Google’s 8.8.8.8 and 8.8.4.4). The algorithm detects wildcard roots using a minimal number of queries to ensure precise results. Here’s a typical bruteforce workflow:
# Bruteforce subdomains with automatic wildcard filtering
puredns bruteforce wordlist.txt example.com --resolvers public-resolvers.txt
# Use custom trusted resolvers for validation
puredns bruteforce wordlist.txt example.com \
--resolvers public-resolvers.txt \
--resolvers-trusted trusted-resolvers.txt
# Bruteforce multiple domains from a file
puredns bruteforce all.txt -d domains.txtThe tool handles DNS load-balancing edge cases during wildcard detection—a detail that separates it from naive implementations. Some wildcard configurations rotate through multiple IP addresses to distribute load. Puredns accounts for this by circumventing DNS load-balancing during wildcard detection, as explicitly mentioned in its feature list.
The third phase validates against trusted resolvers. Every domain that survived wildcard filtering gets re-queried against your trusted resolver set. This catches DNS poisoning from sketchy public resolvers that returned fake answers during the MassDNS phase. Only domains that resolve correctly through trusted infrastructure make it into the final output.
Puredns is built for pipeline integration. It reads from stdin and supports quiet mode, making it composable with other tools:
# Chain with other recon tools
cat subdomains.txt | puredns resolve --resolvers resolvers.txt -q | httpx
# Resolve domains from stdin
subfinder -d example.com -silent | puredns resolveThe tool saves multiple output files: a clean list of valid domains, identified wildcard roots, and sanitized MassDNS output containing only validated entries. This separation lets you analyze what was filtered and why, rather than just getting a binary yes/no on each domain.
One architectural constraint: puredns requires the MassDNS binary in your PATH or specified via --bin. It’s a wrapper, not a reimplementation. This keeps the codebase focused on the filtering logic rather than reinventing a high-performance DNS stub resolver in Go. The tradeoff is an additional installation step and potential version compatibility concerns.
Gotcha
The dependency on MassDNS is both puredns’s strength and its friction point. You can’t just go install and run—you need to compile MassDNS separately, which requires make and a C compiler. On shared hosting or restricted environments, this can be a blocker. The README provides Debian-based installation instructions, but other platforms may require troubleshooting.
Resolver list quality directly determines result quality. Puredns is only as good as the public resolvers you feed it. Those lists degrade over time as servers go offline, get rate-limited, or start returning poisoned responses. You can’t just download a resolver list once and forget about it—maintaining a working set requires ongoing curation. The FAQ mentions this, but it’s worth emphasizing: expect to spend time validating and refreshing your resolver lists, or your results will deteriorate. Tools exist to test resolver health, but it’s manual overhead.
The validation phases add latency. If you’re comparing raw MassDNS speed to puredns, MassDNS will always win on throughput because it skips wildcard detection and validation. Puredns trades speed for correctness. On massive wordlists (tens of millions of permutations), the validation overhead compounds. You need to decide whether clean results are worth the extra time, or if you’d rather post-process noisy output yourself.
Verdict
Use puredns if you’re doing bug bounty reconnaissance, penetration testing, or attack surface mapping where result accuracy matters more than raw speed. It’s the right tool when you need to bruteforce subdomains at scale without drowning in wildcard false positives or wasting time on DNS-poisoned garbage. The automatic filtering justifies the setup overhead for anyone running regular recon operations. Skip it if you’re doing one-off DNS lookups on small domain lists—standard tools like dig or host are simpler. Also skip if you need real-time streaming results and can’t tolerate validation latency, or if you’re in an environment where compiling MassDNS is impossible. And definitely skip if you don’t want to maintain a resolver list; without good resolvers, puredns loses its advantage over simpler alternatives.
