dnscan: Why 86,000 Zone Transfers Make Better Subdomain Wordlists

Hook

Most subdomain brute-forcing tools use wordlists compiled from dictionaries or random guessing. dnscan's wordlists come from analyzing 86,000+ actual zone transfers, sorted by real-world subdomain popularity—a fundamentally different approach to reconnaissance.

Context

Subdomain enumeration is a critical first step in any security assessment or attack surface mapping exercise. Traditional tools relied on either DNS zone transfers (which administrators learned to disable) or brute-forcing with generic wordlists pulled from common words or arbitrary technical terms. The problem? Generic wordlists waste time testing unlikely candidates while missing organization-specific patterns.

The gap between passive reconnaissance (which misses internal or recently created subdomains) and active brute-forcing (which is slow and noisy) left security professionals without an efficient middle ground. dnscan emerged as a Python-based solution that bridges this gap by using empirical data—actual subdomain patterns from thousands of real zone transfers—to prioritize likely candidates first. It's not about guessing what subdomains might exist; it's about testing what statistically does exist based on how organizations actually name their infrastructure.

Technical Insight

dnscan implements a three-phase enumeration strategy that maximizes discovery while minimizing wasted DNS queries. First, it attempts zone transfers (AXFR requests) against all discovered nameservers for the target domain. If successful, this immediately reveals the complete DNS zone without any brute-forcing. When zone transfers fail—which is the common case on properly configured domains—dnscan queries TXT and MX records to gather additional intelligence before moving to the resource-intensive subdomain brute-forcing phase.

The brute-forcing engine uses threaded parallelism to send DNS queries concurrently, with configurable thread counts up to 32. Here's how a typical scan operates:

# Example usage showing the multi-threaded approach
python dnscan.py -d example.com -w subdomains-10000.txt -t 16

# The tool will:
# 1. Attempt zone transfer against example.com nameservers
# 2. Query TXT and MX records
# 3. Spawn 16 threads to brute-force subdomains from wordlist
# 4. Report discovered subdomains with their IP addresses

What distinguishes dnscan is its wordlist methodology. The included wordlists (subdomains-10000.txt, subdomains-100.txt, etc.) aren't arbitrary—they're frequency-sorted based on analysis of 86,000+ zone transfers. This means common patterns like www, mail, dev, api, and staging appear early in the wordlist, while obscure or organization-specific patterns appear later. This ordering dramatically improves time-to-first-result in reconnaissance scenarios.

The tool supports recursive subdomain discovery, which is where things get interesting for comprehensive enumeration:

# Recursive scanning with depth limit
python dnscan.py -d example.com -w subdomains-1000.txt -r 2

# This discovers subdomains, then scans each discovery:
# 1. Find api.example.com
# 2. Automatically scan *.api.example.com
# 3. Find v2.api.example.com
# 4. Stop at depth 2 (prevents infinite recursion)

Recursive scanning exploits a common organizational pattern where teams create nested subdomain hierarchies (staging.api.example.com, internal.vpn.example.com). By automatically scanning discovered subdomains, dnscan uncovers infrastructure that wouldn't appear in any wordlist.

The alteration scanning feature generates permutations by adding common prefixes and suffixes to discovered domains:

# Alteration scanning generates ~60 variants per domain
python dnscan.py -d example.com -a

# For each found subdomain (e.g., 'api'), tests:
# api-dev, api-prod, api-staging, api-01, api-02
# dev-api, prod-api, staging-api, old-api, new-api
# etc.

This catches naming conventions where teams append environment indicators or version numbers. However, the tool generates approximately 60 permutations per domain, which creates a multiplicative explosion—scanning 1,000 base subdomains generates 60,000 alteration queries.

Under the hood, dnscan uses dnspython for DNS resolution, which provides reliable RFC-compliant query handling and supports custom DNS resolvers. You can point scans at specific resolvers to bypass rate limiting or use internal DNS servers:

# Use Google's DNS for resolution
python dnscan.py -d example.com -n 8.8.8.8

# Use internal DNS server for discovering internal subdomains
python dnscan.py -d corp.internal -n 10.0.0.53

The ability to specify custom resolvers is critical for penetration testing scenarios where you've gained access to an internal network and want to discover subdomains that only resolve internally.

Gotcha

The 32-thread cap is a significant limitation for large-scale reconnaissance. Modern tools like massdns can handle thousands of concurrent queries, making them orders of magnitude faster for massive wordlists. If you're scanning with 100,000+ subdomain candidates, dnscan's threading model becomes a bottleneck.

Wildcard subdomain handling is acknowledged in the documentation as problematic. Some domains are configured to return valid DNS responses for any subdomain query (e.g., *.example.com resolves to a catch-all IP). dnscan attempts to detect this by checking random subdomains first, but the implementation can produce false positives. The recursive wildcard scanning mode is explicitly flagged as "very slow" in the help text—a rare admission that suggests you should avoid it unless absolutely necessary. Additionally, alteration scanning's 60x query multiplication can turn a quick reconnaissance scan into an hours-long operation. The tool doesn't appear to support modern passive reconnaissance sources like certificate transparency logs, which have become standard in contemporary subdomain enumeration tools. This means you're missing subdomains that could be discovered without sending a single DNS query.

Verdict

Use if: You're conducting targeted penetration testing or bug bounty reconnaissance where empirically-derived wordlists provide better hit rates than generic dictionaries, you need zone transfer attempts as part of your methodology, or you're working with custom DNS resolvers in internal network scenarios. The recursive scanning and alteration features are valuable when you've already found initial footholds and want to expand laterally through subdomain hierarchies. The data-driven wordlists are genuinely superior for common infrastructure discovery. Skip if: You need high-speed scanning with massive wordlists (use massdns instead), you want passive reconnaissance via certificate transparency or search engine APIs (use subfinder or amass), or you require active maintenance and modern features. The project's minimal recent activity and lack of integration with contemporary data sources make it less suitable as a primary tool in 2024, though the wordlists themselves remain valuable assets you could extract for use with other tools.