A machine-curated list of validated public DNS resolvers, continuously refreshed by an automated Trickest pipeline to feed subdomain enumeration and recon tooling during authorized assessments.
| Tool | trickest/resolvers — an automatically validated list of reliable public DNS resolvers for enumeration tooling |
| Category | Reconnaissance data / DNS infrastructure wordlist |
| Primary Use | Supplying high-quality resolver lists to tools like massdns, dnsvalidator, or subfinder during authorized subdomain enumeration |
| Safe Use | Use within authorized penetration tests, bug bounty programs with defined scope, internal labs, and defensive DNS research only |
| Telemetry Note | Using third-party open resolvers means your enumeration queries are visible to those resolver operators; defenders can detect high-volume DNS queries from scanner subnets against their infrastructure |
Most security professionals who have run large-scale DNS enumeration know the pain of a stale resolver list. Subdomain brute-forcing tools like massdns chew through thousands of candidate hostnames per second, and every dead or misbehaving resolver in your list translates directly into lost resolution coverage and false negatives. trickest/resolvers attacks this operational problem head-on: it is not a scanner itself, but a continuously refreshed dataset of validated public DNS resolvers, maintained by an automated Trickest workflow rather than by occasional manual curation. For anyone running authorized recon pipelines, it functions as the fuel supply for the enumeration stage.
The repository, MIT-licensed and sitting at just over a thousand stars on GitHub, is deliberately minimal in structure. It ships three consumable artifacts. The first, resolvers.txt, is a plain list of resolver IP addresses formatted so you can pass it straight into whatever DNS enumeration tool you use — no parsing or transformation required. The second, resolvers-extended.txt, contains the same resolvers enriched with metadata: the organization each server belongs to, its country, and a count of how many times the pipeline has detected it as valid across historical runs. The third, resolvers-trusted.txt, is a curated shortlist of resolvers from well-known organizations such as Cloudflare and Google, which the README explicitly recommends using to re-validate results obtained with the main list.
That three-tier split reflects a genuinely sound methodology, and it is worth understanding why. The big list maximizes throughput and coverage, but open resolvers on the public internet are an unreliable population — some hijack responses, some rate-limit aggressively, some disappear overnight. The trusted list, anchored to organizations with reputational stakes in DNS correctness, trades volume for fidelity. The sensible pattern the README implies — resolve broadly first, then re-validate discovered hostnames against resolvers-trusted.txt — mirrors how a careful operator would structure any noisy-then-precise enumeration pipeline during an authorized engagement.
The How it Works section is the most interesting part of the README, because it documents a full data supply chain rather than a one-time scrape. The initial dataset is aggregated from ten distinct upstream sources: public-dns.info's nameserver list, resolver lists bundled with bass, janmasarik/resolvers, proabiral/Fresh-Resolvers, geraldino2/jart, cxosmo/dns-resolvers, the resolver list shipped with blechschmidt's massdns, zeroc00I/test_github_action, the resolvers list from carlospolop's Auto_Wordlists, and a community-contributed file resolvers-community.txt maintained in the repo itself. Each source is credited individually, which is a good sign of provenance hygiene in a dataset whose entire value is reliability.
From there, the pipeline de-duplicates the merged mega-list with sort -u, chunks it into smaller pieces, and spins up multiple parallel instances of dnsvalidator — the validation tool from vortexau credited jointly with codingo. One validation pass is not considered sufficient: the workflow runs a second round of dnsvalidator specifically to weed out false positives that survived the first pass. This double-validation loop is what distinguishes the project from the many static resolver lists that circulate in GitHub gists and slowly rot. The README states plainly that the workflow is scheduled to run constantly, so the committed lists in the repo are the output of a rolling process, not a snapshot.
The enrichment stage adds context that few competing lists provide. After validation, the final resolver list is passed through a whois script that queries APNIC's API to determine the organization and country each resolver belongs to. That data lands in resolvers-extended.txt, and the pipeline also accumulates a longitudinal validity count per resolver across all historical runs. The README describes an implicit promotion mechanism: a resolver that proves valid enough times may earn a place in the next file, meaning sustained reliability is the criterion for advancement within the dataset rather than mere presence in an upstream source.
For an operator, the practical integration point is trivial: resolvers.txt is formatted for direct consumption by tools that accept a resolver-list flag, and most modern enumeration tooling — massdns with its -r resolver option, or similar parameters in frameworks like subfinder-style pipelines — will accept it verbatim. Because the list is just data, there is no installation beyond a git clone of the repository or a raw fetch of the individual text files. Keeping a local copy synchronized with upstream is a reasonable habit, since resolver population changes are precisely what the constant scheduling is designed to capture.
There is also a defensive angle worth naming. If you run DNS infrastructure or monitor an enterprise network, the existence of curated public resolver lists is directly relevant to your detection posture. High volumes of NXDOMAIN or wildcard-probing queries originating from cloud VPS ranges against your authoritative nameservers are the signature of enumeration driven by exactly this kind of tooling, and resolver-side logging on any open resolvers you operate will surface scanner traffic. Conversely, defenders building lab environments can use resolvers-trusted.txt as a known-good baseline when testing how their DNS monitoring responds to burst query patterns.
The community model deserves a note as well. Contributions flow through pull requests that edit resolvers-community.txt, which then feeds the aggregation stage of the next pipeline run; issues and the project's Discord handle other feedback. This means the dataset is not purely machine-generated — human submissions enter the funnel, but they must survive the same dnsvalidator gauntlet as every other source before reaching the shipped lists. The commercial framing around trickest.com, where users are invited to customize or build their own versions of the workflow, is visible but does not gate access to the data itself, which remains freely available under MIT terms.
Caveats are the usual ones for third-party open resolvers. You are sending your enumeration queries through infrastructure operated by unknown parties, which is a meaningful consideration for engagement opsec — query logs on those resolvers can reveal your target domains and brute-force wordlists. The organization and country metadata in resolvers-extended.txt helps here, letting you filter out resolvers in jurisdictions or organizations you would rather not leak scope to, and the resolvers-trusted.txt tier partially mitigates the concern for validation passes. As with any recon asset, scope discipline applies: this list enables enumeration at scale, and scale belongs inside the boundaries of an authorized engagement, a bug bounty program with defined scope, or your own laboratory infrastructure.
Taken as a whole, trickest/resolvers is a small repository that solves a real, recurring logistical problem in DNS reconnaissance with more engineering rigor than its simple file list suggests. The multi-source aggregation, double dnsvalidator passes, APNIC-based enrichment, longitudinal validity counting, and constant rescheduling combine into a dataset you can reasonably treat as fresh. If your authorized workflows depend on mass DNS resolution, this is one of the few resolver lists where the maintenance mechanism is documented, verifiable, and continuous — which is exactly the property that matters when your enumeration results are only as good as the resolvers behind them.
trickest/resolvers.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.