shuffleDNS: massDNS wrapper for subdomain bruteforce and wildcard filtering

Why shuffleDNS exists for DNS reconnaissance

shuffleDNS addresses a specific gap between raw subdomain wordlists and useful DNS results. A wordlist can produce many candidate names, but candidates alone do not establish that a name resolves. A DNS response can also come from a wildcard rule, producing misleading results across names that may not exist independently. shuffleDNS is intended for active subdomain enumeration and resolution workflows that need to address both issues.

The project is a wrapper around massDNS, not a replacement DNS resolution library. It uses massDNS for the underlying resolution work while adding a Go command-line interface, input and output handling, bruteforce mode, wildcard handling, and workflow integration. This makes it relevant to security researchers and engineers who already have a target domain and can provide the necessary resolver and wordlist data.

The tool also supports standard input and standard output. That matters in pipelines where one discovery stage produces names for another stage. For example, the README shows passive discovery with subfinder followed by shuffledns resolution. The resulting output is described as unique and valid subdomains, although the exact filtering details depend on the selected mode and DNS responses.

shuffleDNS does not generate a complete intelligence picture. It does not discover web content, inspect applications, or validate application-layer behavior. Its scope is DNS-oriented candidate generation and resolution.

The massDNS-backed processing path

The repository describes three execution modes: `bruteforce`, `resolve`, and `filter`. In bruteforce mode, shuffleDNS receives a domain and a wordlist, generates subdomain permutations, and sends the resulting DNS work to massDNS. The README specifically identifies the `-w` flag as the wordlist input and says that permutations are resolved through massDNS.

In resolve mode, the tool reads subdomains from a file supplied with `-list` or from standard input. The domain is still supplied with `-d`, and the resolver list is supplied with `-r`. This mode is intended when candidate names already exist and the immediate task is to resolve and filter them.

Wildcard handling is the distinguishing feature. The README says that shuffleDNS tracks how many subdomains point to an IP. When the number rises beyond a small threshold, the tool checks whether the apparent results are caused by DNS wildcards. It also documents `-sw` for checking every found subdomain and `-wt` for controlling concurrent wildcard checks. The `-wo` option can dump wildcard IPs to an output file. The exact threshold and full decision sequence are not specified in the README excerpt, so those details should be confirmed in the source if they affect a policy.

The Go module dependencies include DNS and retry packages, including `github.com/miekg/dns`, `github.com/projectdiscovery/dnsx`, and `github.com/projectdiscovery/retryabledns`. The repository also includes a `Dockerfile`, which confirms that the project is packaged as a command-line application. These implementation details support a CLI-oriented orchestration layer, while the README remains the source for the user-facing behavior.

Installing shuffleDNS and preparing massDNS

The README states that Go 1.24 or later is required for installation. The following command installs the latest version through Go tooling:

go install -v github.com/projectdiscovery/shuffledns/cmd/shuffledns@latest

This installs the command from the module path named in the README. The README does not describe a separate binary download or release archive installation procedure.

massDNS is a prerequisite. The README says that shuffleDNS can automatically detect the binary when it is placed in `/usr/bin/massdns` or `/usr/local/bin/massdns`. On Windows, the path to the massDNS binary must be supplied. The general dependency command shown by the help text is:

shuffledns -h

That command displays supported switches. The `-m` flag accepts the path to the massDNS binary, while `-mcmd` allows additional massDNS commands. The README does not give a single universal installation command for massDNS, so the massDNS project’s compilation instructions are the appropriate reference.

The tool also needs a list of valid resolvers and, for bruteforce, a wordlist. The README points to dnsvalidator for resolver-list generation and gives a public wordlist URL as one possible source. These are operational inputs, not optional conveniences for the basic workflows described in the documentation. A missing massDNS binary, resolver file, or wordlist can prevent the corresponding operation from starting.

First resolve and bruteforce runs with shuffleDNS

For an existing list of subdomains, start with resolve mode. The command below is copied from the README and reads `example-subdomains.txt` for the `example.com` target while using `resolvers.txt` for DNS resolution.

shuffledns -d example.com -list example-subdomains.txt -r resolvers.txt -mode resolve

The command returns results for the supplied candidates. The help output also documents `-o` for writing results to a file and `-j` for NDJSON output. Those options are useful when a later stage needs a stable file or structured records, but the README does not specify the complete JSON schema.

For wordlist-based enumeration, use bruteforce mode:

shuffledns -d hackerone.com -w wordlist.txt -r resolvers.txt -mode bruteforce

The target domain comes from `-d`, the candidate words come from `wordlist.txt`, and the resolver list comes from `resolvers.txt`. Standard input is supported as an alternative. The README gives this exact form:

echo hackerone.com | shuffledns -w wordlist.txt -r resolvers.txt -mode bruteforce

For pipeline use, the README pairs shuffledns with subfinder:

subfinder -d example.com | shuffledns -d example.com -r resolvers.txt -mode resolve

The documented workflow is therefore either resolve known names or generate candidates from a wordlist. The output should be treated as DNS results from the configured resolvers, not as proof that every name hosts a distinct service.

Wildcard filtering and operational controls

Wildcard DNS can make bruteforce output misleading. A provider may answer many unrelated labels with the same address, so a tool that only records successful DNS answers can report names that are not independently meaningful. shuffleDNS addresses this by tracking repeated IP behavior and performing wildcard checks when the observed pattern warrants them.

The `-sw` flag changes the breadth of that analysis. Without a detailed algorithm specification in the README, the safest operational interpretation is that normal wildcard handling is selective, while strict wildcard checking is intended to inspect all found subdomains. The `-wt` flag sets the number of concurrent wildcard checks, whose documented default is 250. The main resolver concurrency control is `-t`, whose default is 10000 concurrent massDNS resolves.

These controls have a practical tradeoff. Increasing concurrency can reduce elapsed time, but it also increases pressure on the resolver path and may make failures or rate limits harder to distinguish from genuine DNS results. The README documents retries as well, with `-retries` defaulting to 5. It does not document retry policy details, resolver health handling, or how network failures are represented in the final output, so operators should inspect those areas before using high concurrency against a sensitive resolver set.

The `-silent` option is documented as showing only subdomains. That can simplify shell pipelines, but it removes some contextual output. The `-v`, `-nc`, `-o`, and `-j` flags control verbosity, color, output files, and NDJSON respectively.

Where shuffleDNS is the wrong tool

The main constraint is dependency and input preparation. shuffleDNS cannot perform the documented operations without massDNS, and the README explicitly says that the tool needs a list of valid resolvers. A wordlist is also required for bruteforce. This is a meaningful difference from tools that include their own resolver strategy or derive candidates from a passive source.

It is also not a general DNS dataset cleaner. Its wildcard logic is designed around subdomain enumeration and IP repetition, while the README does not describe handling of CNAME chains, record-type-specific policies, DNS zones with unusual delegation, or authoritative-only validation. Do not infer those capabilities from the tool’s DNS dependencies or from its ability to write wildcard IPs.

Compared with invoking massDNS directly, shuffledns adds a higher-level interface, wordlist permutation flow, modes, wildcard handling, and pipeline-oriented input and output. Compared with a passive discovery tool such as subfinder, it actively queries names derived from a wordlist or supplied candidates. That makes it a better fit when DNS resolution and filtering are the immediate task, but a weaker fit when the requirement is passive discovery without active queries.

The project is licensed under GPL-3.0. That is a repository and distribution fact, not legal advice. Users distributing a modified or linked build should review the license obligations applicable to their use.

Maintenance status and upgrade considerations

The repository is not archived. Its last push was on 2026-10-14, so it has recent repository activity based on the stated maintenance facts. The release history includes v1.2.1 and v1.2.0 on 2025-12-09 and v1.1.0 on 2024-05-21. Those dates indicate published releases, but they do not by themselves define compatibility for every massDNS or Go environment.

Upgrading shuffleDNS can involve more than replacing the Go binary. The command’s operation depends on an external massDNS binary, resolver lists, and wordlists. The Dockerfile builds massDNS from its `master` branch and installs shuffleDNS through `@latest`. That Dockerfile is useful evidence of a containerized setup, but it also means a container build follows external repository state rather than pinning a documented massDNS release in the shown configuration.

The `go.mod` requires Go 1.24.0, while the README says Go 1.24+ is needed for installation. The repository Dockerfile uses `golang:1.25.5-alpine` for its build stage. The README does not document a migration procedure for resolver formats, output schema changes across releases, or compatibility guarantees between shuffledns and every massdns version. Verify those points before upgrading an automated pipeline.

Editorial conclusion

Adopt shuffleDNS when your workflow needs a massDNS-backed wrapper with bruteforce, resolution, stdin integration, and wildcard checks. Do not treat it as a standalone discovery engine, because the README requires external massDNS installation, resolver lists, and wordlists. Verify first that massDNS is available on your platform, that resolver input is appropriate, and that wildcard behavior matches the target domain before relying on its filtered output.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. projectdiscovery/shuffledns on GitHub
3. Project website
4. README
5. Releases