resolvers: a continually revalidated list of public DNS resolvers

Three files, and they answer three different questions

The repository is small in structure and the three data files are the whole product.

`resolvers.txt` is a simple list of resolver IP addresses, which you can pass directly to your DNS enumeration tool. That is the file most people want, and its simplicity is the point.

`resolvers-extended.txt` has all of the resolvers in `resolvers.txt` with additional information about each server, including the organization it belongs to, its country, and how many times it has been detected as valid. The frequency counter is the interesting field, and the documentation explains its meaning: if a resolver is valid enough times, it may earn its place in the next file.

`resolvers-trusted.txt` is a list of trusted resolvers from organizations like Cloudflare and Google. The recommendation attached to it is that you use this list to re-validate the results you get with the main resolvers.

That third file is a design decision worth pausing on. The main list is a large set of addresses whose quality is described statistically. The trusted list is a small set of addresses whose operators are known. Running your enumeration against the large list tells you what the open internet sees, and re-validating the answers against the trusted list tells you whether the answer is an artefact of a broken resolver rather than the truth.

There is also a fourth file, `resolvers-community.txt`, which is the contribution mechanism rather than an output.

The repository contains a `LICENSE` file, the README, a `banner.png` and a `resolvers.png` diagram of the workflow, plus the four text files. The homepage is `trickest.com`.

Ten sources merged, then validated twice

The How it Works section describes a workflow that runs continuously, and the order of the steps is the substance of the project.

A Trickest workflow creates an initial dataset of resolvers from various sources and then uses multiple instances of dnsvalidator to validate and re-validate this dataset and make it as reliable as possible.

The initial dataset comes from ten sources. The Public DNS Server List. A list of provider DNS servers collected from bass, contributed by Abss0x7tbh. janmasarik/resolvers, contributed by janmasarik. A list of DNS servers contributed by the community in `resolvers-community.txt`. proabiral/Fresh-Resolvers, contributed by proabiral. geraldino2/jart, contributed by geraldino2. cxosmo/dns-resolvers, contributed by cxosmo. The resolvers list from Massdns, contributed by blechschmidt. zeroc00I/test_github_action, contributed by zeroc00I. And the resolvers list from Auto_Wordlists, contributed by carlospolop.

Then the pipeline does this. The mega list of resolvers is sorted with `sort -u` and split up into smaller chunks. Multiple instances of dnsvalidator are created to validate the resolver lists in parallel. Then another round of dnsvalidator runs to weed out any false positives that survived the previous step.

That second validation round is the part that makes the dataset worth having. A single validation pass produces a list of addresses that answered once, which includes resolvers that were up at that moment and addresses that respond to anyone. Two rounds with a re-check weeds out the transient ones.

The tooling is credited specifically. Huge thanks to vortexau and codingo are named for the dnsvalidator work, and the link points at vortexau's dnsvalidator project.

The final resolvers list is passed to a `whois` script, which uses APNIC's API, to find out the organization and country to which each resolver belongs. And in the end, the workflow counts the number of times it found each resolver to be valid throughout all the previous runs and writes the frequency data to `resolvers-extended.txt`.

This workflow is scheduled to run constantly.

Frequency is the quality signal, and it is a relative one

The extended file's most useful column is the count of how many times a resolver was found valid, and understanding what that number means matters more than the number itself.

The count is accumulated across all the previous runs of the workflow, not reset per run. So it is a measure of reliability over time, and a resolver that has been in the list for a year has had far more opportunities to be counted valid than one that appeared last week. The documentation says the count is written to `resolvers-extended.txt` and that a resolver valid enough times may earn its place in the next file, which is the promotion mechanism between the raw dataset and the published list.

That has a consequence for interpretation. A high count means a resolver has been consistently reachable, and a low count means it has not. Neither tells you whether the resolver is fast, whether it is in a friendly jurisdiction, or whether it logs queries. The dataset measures availability, and that is genuinely the property you want when you are looking for resolvers to enumerate with, because an address that answers one query out of a thousand is not a resolver you can use at volume.

The organisation and country fields come from a whois lookup against APNIC's API. That is a regional registry, so the country attribution follows the allocation rather than necessarily the physical location of the server, and for a list assembled from open sources that is the best available approximation rather than a verified fact.

The two-source structure of the trust model is worth restating. `resolvers.txt` is the working set, and `resolvers-trusted.txt` is the set of resolvers from organisations like Cloudflare and Google, which the documentation recommends for re-validating results. In practice that means you use the large list to gather and the small list to check, and a discrepancy between the two is a signal worth investigating rather than noise.

Contributing is a text file, and the project wants it that way

The contribution model is deliberately low friction. All contributions are welcome, and you can create a pull request editing `resolvers-community.txt` to contribute new DNS servers to the project. For any other suggestions or questions, you can create a new ticket via GitHub issues, tweet at the project, or join the conversation on Discord.

That is a sensible design for a dataset. The validation workflow is what makes the published list trustworthy, and the community file is the input to it. A contributed address is not a claim that the address works, it is a candidate, and the workflow decides whether it survives. The authors of the ten upstream sources are credited by name in the README, which is the same courtesy extended to community contributors.

The project also asks for a second kind of contribution. Sign up for a demo on trickest.com to customize this workflow to your use case, get access to many more workflows, or build your own from scratch. The README frames this as a belief in the value of tinkering, and the workflow itself is a Trickest product rather than a set of shell scripts in the repository.

That has a consequence for anyone considering depending on this. The data is published as plain text files under the MIT licence, so using the lists is straightforward. The generation pipeline, the validation history and the frequency data, however, live in the Trickest platform rather than in the repository, which means the history behind a given count is not something you can audit from the repository alone.

The repository has no GitHub releases, and the last push was on 2026-10-15 with the repository not archived, so the files are being regenerated continuously and the list changes underneath you. That is the intended behaviour, and it is also why the counts exist.

What this dataset is not for

There is a limitation that follows from what the project measures, and it is worth being blunt about it.

The lists are a resource for DNS enumeration, and the topic tags say so plainly: dns, infosec, network, pentesting, red-team, security-tool, brute-force, bug-bounty. The workflow validates that an address answers DNS queries. It does not evaluate what an operator does with the query, and the country and organisation fields are attribution from a whois record, not a statement about the resolver's logging or ownership.

So the obvious misuse is treating the list as a set of resolvers to configure your own system with. Nothing in the project supports that, and the trusted list, with its Cloudflare and Google entries, exists for a different reason: to check the answers the open list gives you.

There is a second consideration that the project does not address, which is the point of the data itself. A list of open DNS resolvers is a list of servers that will answer queries from anyone. The addresses are public in the repository, which is the point, but it does mean that anyone can use the same pool. For enumeration work that is a feature, since you get resolvers that are not yours and are not rate-limited against you. For anything else it is a different situation entirely.

A third limit is availability over time. The dataset is a snapshot of a moving population. The addresses that were valid during the workflow run may not be valid later, and a resolver that has been stable for a year can be decommissioned. The frequency data tells you about the past. The documentation does not offer a guarantee about the present, and a tool that depends on the list needs to handle an address that stops answering.

The alternative, and it is a straightforward one, is to run your own resolvers, or to use a resolver you have a relationship with. For enumeration at scale, some open resolvers are still the practical answer, which is why this dataset exists. For anything you depend on, they are not.

Editorial conclusion

resolvers fits a security researcher or bug bounty hunter who needs a large pool of working public resolvers for DNS enumeration, and who wants the pool to be continuously revalidated rather than scraped once. It does not fit an application that needs resolvers for privacy or availability, since a public resolver list is a scanning resource rather than a service to depend on, and it does not fit a workflow that needs attribution of who operates each address. Verify first that the addresses in the file you download are still live at the time you use them, since validity is measured in frequency rather than guaranteed, that your enumeration tool accepts a plain list of IP addresses as the documentation describes, and that the extended file's organisation and country fields match the network you are working in, since the whois lookup is regional.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. trickest/resolvers on GitHub