ShuffleDNS: How 10,000 Concurrent DNS Queries Reveal Hidden Subdomains
Hook
While most DNS bruteforce tools struggle to query 100 domains per second, shuffleDNS casually processes 10,000 concurrent DNS resolutions by default—a difference that turns a week-long enumeration job into a 30-minute operation.
Context
Subdomain enumeration is foundational to security reconnaissance, bug bounty hunting, and attack surface management. Before tools like shuffleDNS emerged, security researchers faced a painful choice: use slow, Python-based DNS bruteforce tools that could take days to process large wordlists, or wrestle with massdns directly—a blazingly fast C-based resolver that required manual pipeline construction, offered no wildcard filtering, and drowned users in false positives.
The problem wasn’t just speed. Wildcard DNS records—where *.example.com resolves to a catch-all IP—create noise that ruins enumeration results. A naive tool querying random123.example.com might report thousands of “valid” subdomains that all point to the same parking page. ProjectDiscovery built shuffleDNS as a Go wrapper around massdns that preserves the speed while adding intelligent wildcard detection, wordlist management, and Unix-friendly pipeline integration. It bridges the gap between massdns’s raw performance and the filtering logic reconnaissance workflows actually need.
Technical Insight
ShuffleDNS operates through three distinct modes that separate concerns cleanly: bruteforce mode generates subdomain candidates from wordlists, resolve mode validates pre-discovered subdomains from passive sources, and filter mode post-processes raw massdns output. This architectural decision reflects a philosophy of composability—each mode does one thing well and integrates into larger reconnaissance pipelines.
The bruteforce workflow demonstrates the tool’s design elegance. When you run shuffleDNS with a wordlist and target domain, it doesn’t query DNS directly. Instead, it generates permutations, writes them to temporary files, shells out to the massdns binary with massive concurrency settings, then filters the results:
# Basic bruteforce with wildcard filtering
shuffledns -d example.com \
-w wordlist.txt \
-r resolvers.txt \
-o valid-subdomains.txt
# Pipeline integration: passive discovery then active validation
subfinder -d example.com -silent | \
shuffledns -d example.com -r resolvers.txt -mode resolve
# Extreme scale: 10M wordlist with custom massdns settings
shuffledns -d example.com \
-w huge-wordlist.txt \
-r resolvers.txt \
-t 5000 \
-massdns /usr/local/bin/massdnsThe wildcard detection system is where shuffleDNS demonstrates real intelligence. Rather than naively checking if *.example.com resolves (which misses complex wildcard configurations), it tracks the ratio of subdomains to unique IP addresses during enumeration. When multiple subdomains start pointing to the same IP with suspicious frequency, shuffleDNS triggers hierarchical wildcard verification.
Here’s the algorithm in practice: if 50 discovered subdomains map to only 3 IP addresses, the tool generates random subdomains like 8f3a9b2c.example.com and checks if they also resolve to those IPs. If they do, it marks the entire IP range as wildcard. But it doesn’t stop there—it performs this check at multiple subdomain levels. For admin.dev.example.com, it tests wildcards at *.dev.example.com, *.example.com, and even *.admin.dev.example.com independently. This multi-level approach catches sophisticated wildcard configurations that simpler tools miss.
The concurrency model leverages massdns’s core strength while adding Go-based orchestration. MassDNS handles the actual DNS queries using asynchronous I/O and can manage tens of thousands of concurrent requests without threading overhead. ShuffleDNS manages the preprocessing (wordlist permutation, input batching) and postprocessing (wildcard filtering, output formatting) in Go, which excels at concurrent file I/O and text processing:
// Conceptual flow of how shuffleDNS orchestrates massdns
// 1. Generate subdomain candidates
subdomains := generatePermutations(wordlist, domain)
// 2. Write to temporary file for massdns consumption
tempFile := writeTempFile(subdomains)
// 3. Execute massdns with high concurrency
results := executeMassdns(tempFile, resolvers, concurrency)
// 4. Filter wildcards using IP frequency analysis
validSubdomains := filterWildcards(results, domain)
// 5. Perform hierarchical wildcard verification
finalResults := verifyMultiLevelWildcards(validSubdomains)The resolver management deserves attention too. Unlike tools with built-in resolver lists, shuffleDNS requires you to provide your own resolver file—a plain text list of DNS servers. This design choice reflects a security-conscious philosophy: public DNS resolvers change constantly, some rate-limit aggressively, and using stale or compromised resolvers can poison your results. By forcing users to maintain their own resolver lists (often sourced from projects like public-dns.info or generated from their own infrastructure), shuffleDNS ensures you understand and control a critical dependency.
The stdin/stdout pipeline integration makes shuffleDNS a Unix philosophy exemplar. You can chain it with subfinder for passive discovery followed by active validation, feed it output from other tools, or integrate it into automated reconnaissance frameworks. The -mode resolve flag specifically optimizes for this use case—it skips wordlist permutation and focuses purely on validating a provided list of subdomains, perfect for confirming passive discoveries are still live.
Gotcha
The hard dependency on massdns is both shuffleDNS’s superpower and its biggest operational headache. You can’t just go install and start working—you need to compile and install massdns separately, configure its path, and understand its quirks. On Windows, this becomes particularly painful since massdns doesn’t officially support the platform. You’ll need WSL or a Linux VM, adding friction that makes shuffleDNS unsuitable for quick, casual DNS lookups.
Resolver list management creates another operational burden. Unlike tools with built-in fallback resolvers, shuffleDNS refuses to run without a resolver file. For new users, this creates a frustrating cold-start problem: you need to research resolver sources, download or generate lists, test them for responsiveness, and maintain them over time as resolvers go offline. The tool doesn’t help you here—it assumes you already have reconnaissance infrastructure in place. Similarly, wordlist quality directly determines results quality, and shuffleDNS provides no defaults or recommendations.
The single-operation constraint means you can’t simultaneously bruteforce new subdomains while resolving passive discoveries in one pass. If you want both workflows, you run the tool twice, which doubles execution time and complicates automation scripts. For large-scale operations scanning dozens of domains, this architectural limitation becomes a workflow bottleneck that requires careful pipeline orchestration to work around.
Verdict
Use shuffleDNS if you’re conducting serious security reconnaissance or bug bounty operations where subdomain discovery speed and accuracy at scale matter more than setup convenience. It shines when processing wordlists with millions of entries, validating thousands of passively discovered subdomains, or integrating into automated pipeline workflows where you need wildcard-aware DNS resolution. The massdns performance combined with intelligent filtering makes it the best tool for large-scale enumeration work. Skip it if you need a self-contained, simple DNS tool for small projects, can’t manage external dependencies like massdns installation and resolver lists, or work primarily on Windows without Linux subsystems. For one-off subdomain checks or when you need something that just works out of the box, simpler tools like subfinder (passive only) or self-contained bruteforcers make more sense. ShuffleDNS is infrastructure—powerful but demanding operational maturity to use effectively.
