OneForAll: The Multi-Engine Subdomain Discovery Tool Built for Chinese Pentesters
Hook
While Western security researchers debate the best subdomain enumeration tool, over 9,000 Chinese security professionals have already standardized on OneForAll—a Python framework you’ve probably never heard of.
Context
Subdomain enumeration is the reconnaissance phase that makes or breaks a security assessment. Miss a forgotten staging server or an orphaned API endpoint, and you’ve left the most vulnerable attack surface untouched. Traditional tools like Sublist3r pioneered the category but relied on a handful of search engines and certificate transparency logs. As bug bounty programs matured and attack surfaces grew exponentially, pentesters needed something more comprehensive—a tool that could query dozens of data sources, validate results through multiple techniques, and track discoveries across assessment cycles.
OneForAll emerged from this gap with an explicitly different philosophy: instead of optimizing for speed or simplicity, it prioritizes completeness. The tool orchestrates passive reconnaissance through certificate transparency logs, DNS records, search engines, and third-party APIs, then validates findings with active techniques like DNS brute-forcing. Every discovered subdomain flows through a resolution pipeline, gets validated via HTTP requests, and lands in a SQLite database that persists across runs. For Chinese security researchers navigating the Great Firewall and working with Mandarin-language documentation, OneForAll became the de facto standard—but its architecture has lessons for any pentester tired of stitching together five different tools.
Technical Insight
OneForAll’s architecture centers on a modular collection engine paired with a SQLite persistence layer. The tool isn’t a simple script—it’s a framework where each collection technique lives in its own module under a unified orchestration layer. When you run OneForAll against a target domain, it fires up multiple collection modules simultaneously, each querying different data sources.
The basic invocation demonstrates this multi-source approach:
python3 oneforall.py --target example.com runBehind this simple command, OneForAll executes modules across multiple categories including certificate transparency queries, DNS enumeration, search engine scraping, web crawling, and threat intelligence APIs. The README specifically mentions modules for certificate transparency (with at least 6 modules mentioned), along with active DNS brute-forcing capabilities. Each module dumps results into domain-specific SQLite tables following a naming pattern like example_com_origin_result.
The database schema reveals OneForAll’s tracking philosophy. Four table types exist for each target domain: origin_result stores raw module output, resolve_result holds DNS resolution data, last_result preserves the previous run’s findings (generated after running at least twice), and now_result contains the current assessment’s validated subdomains. This structure enables comparison workflows—you can diff today’s subdomains against previous runs to identify new attack surface.
The brute-forcing module can run independently:
python3 brute.py --target example.com runThis separation lets you skip passive collection when you already have a seed list or when you’re focused purely on dictionary-based discovery. The brute module is mentioned as a standalone component that accepts richer parameters than the main oneforall.py interface.
OneForAll’s validation pipeline performs DNS resolution to filter out dead entries, then attempts HTTP/HTTPS connections to verify actual web services. Port scanning can be configured via the setting.py file, with options for ‘default’, ‘small’, and ‘large’ port ranges. The subdomain takeover module (invokable via takerover.py) checks for subdomain takeover risks.
Configuration lives in two key files: config/setting.py for behavioral parameters (proxy settings, DNS resolvers, module toggles) and config/api.py for third-party API credentials. Many collection modules require API keys:
# config/api.py contains API configuration
# Specific services require API keys for full functionalityThe proxy configuration in setting.py addresses the reality that some collection interfaces are blocked by the Great Firewall and require proxy access to function for Chinese users.
Results export to both CSV and JSON formats (configured via —fmt parameter). The SQLite database (result.sqlite3) enables historical analysis across multiple OneForAll runs against the same infrastructure.
Gotcha
OneForAll’s README explicitly warns that the project is ‘under development’ with updates happening primarily in the master branch. The project maintainers explicitly recommend cloning from master rather than downloading from Releases, as ‘Releases里版本更新缓慢’ (releases are updated slowly). This creates stability uncertainty—you’re running development code during security assessments.
The API key requirement appears to be a setup burden. The README mentions that api.py needs to be configured with API information for various services, and warns users to ignore error messages if they choose not to use certain modules. The tool gracefully handles missing keys by skipping those modules, but you’re left wondering how much coverage you’re sacrificing.
Documentation is heavily Chinese-centric. While English documentation exists at docs/en-us/README.md, the primary README, QQ group support channels (group number 824414244 with verification ‘信息收集’), and most community interaction happens in Mandarin. The project README is primarily in Chinese with an English version as secondary documentation. Non-Chinese speakers can use the tool, but troubleshooting requires navigating Chinese-language resources or using translation tools.
Verdict
Use OneForAll if you need comprehensive subdomain enumeration with historical tracking during penetration tests or bug bounty reconnaissance, especially if you’re comfortable with Chinese-language tooling or willing to invest time configuring API integrations. The SQLite tracking is genuinely valuable for long-term assessments where infrastructure changes matter, and the breadth of collection modules catches subdomains that faster tools miss. It’s the right choice when completeness trumps speed and you don’t mind the configuration overhead. Skip OneForAll if you need production-grade stability with predictable release cycles—the maintainers explicitly recommend running from the development branch. Also skip it if you want minimal setup friction for quick one-off scans, require comprehensive English-first documentation and support, or are uncomfortable running development branch code during client engagements. Western users may find the language barrier and API configuration requirements significant friction compared to alternatives.
