# Fresh-Resolvers: a resolver list that is rebuilt every hour > Fresh-Resolvers is two text files, resolvers.txt and resolvers.ipv6, holding public DNS resolvers that survived a validation pass, refreshed on an hourly schedule. It is a data feed rather than a tool, and its value is entirely in the freshness of the list, which makes the update cadence the thing to check before you rely on it. **proabiral/Fresh-Resolvers** — List of Hourly Updated Fresh DNS resolvers - Repository: https://github.com/proabiral/Fresh-Resolvers - Stars: 115 · Forks: 19 - Language: Unknown - License: not declared - Published: 2026-08-23 · Updated: 2026-08-23 · Language: en - Canonical page: https://hysenlabs.com/projects/proabiral-fresh-resolvers ## Two text files and nothing else in the tree The repository is small in a way that is worth being explicit about, because it changes how you consume it. The top level holds three files: `README.md`, `resolvers.txt` and `resolvers.ipv6`. There is no source code, no build system, no configuration and no documentation directory, and the primary language is not even recorded. The two data files are the product, split by address family so that a consumer can pick the list matching the transport it is doing. Each is a plain list, one resolver per line, in the format that DNS brute-forcing tools already expect. There is no metadata alongside an entry: no measured response time, no country, no indication of whether a resolver is a recursive cache or a filtering resolver, and no record of how many queries a given address has served. So this is a starting set to be tried, not a routing table to be trusted. ## The list is a filtered copy of public-dns.info The provenance is stated directly, and it is short. The candidate addresses come from the nameserver list published at public-dns.info, and they are then run through the DNS Validator project, which is what turns a scraped list into a list of resolvers that answered. Validation is the entire editorial process here: there is no human ranking, no preference for one operator over another, and no attempt to describe what a resolver is good for. The result is pushed into this repository on an hourly basis, which is the claim that matters most and also the claim a consumer can verify cheaply. The validator itself is credited to two named creators, with links to both, so the dependency is a separate project with its own behaviour. If you care how a resolver is judged alive, the answer is in that project's documentation rather than here, since this repository makes no attempt to summarise or reproduce the criteria. ## Built to be piped into massdns, shuffledns and zdns The stated use is as input to other tools, and three are named with links. `massdns` is a parallel DNS resolver designed for high volume work, `shuffledns` resolves a wordlist against a domain using a resolver list of exactly this shape, and `zdns` is a measurement tool that reports what a resolver answers rather than just whether it did. That list is a useful hint about the format, because all three consume a newline-separated file of addresses rather than a structured configuration, which is why the two-file split is enough to be useful. It also suggests the intended user: someone doing subdomain enumeration or resolution measurement at a rate where a handful of well-known public resolvers would be a bottleneck or a single point of failure. If your task is resolving a handful of names, a stock resolver configuration is the better answer and this file adds nothing. ## The hourly commit is the health check, not the star count Because the deliverable is a data file with no code, the commit history is the only signal about whether the pipeline is alive. The project makes that explicit: if the resolvers list has not been updated for more than a day, the instruction is to send a direct message on Twitter to the maintainer. That is a deliberately low bar rather than a precision monitor, which fits a repository where a stalled job is invisible until you try to use the file. Interpreting a recent commit correctly still takes a moment of care, because a push can be a data refresh that came out nearly empty, and an hourly cadence does not tell you how many resolvers survived validation this round. The repository carries no GitHub releases, so there is no version to pin and no changelog; the default branch is `master`, and the practical way to consume this reliably is to track a commit hash or fetch on a schedule and check the file is not empty before using it. ## Unlicensed data with a licensed-looking supply chain The licence situation is the one thing here that deserves a pause before you build a pipeline on it. Neither the repository nor its contents declare a licence, which in the usual reading means the data is not granted for reuse even though it is published and freely fetchable. That is different from the surrounding projects, which carry their own terms: the validator is credited as someone else's work, and the candidate list is published by a separate site. So the chain is licensed source, unvalidated scrape, filter, then unlicensed publication, and the step where permission usually gets complicated is the one with no statement at all. For personal research or an internal tool the practical risk is low, but if the list is going anywhere near redistribution or a commercial pipeline, the question of who permits redistribution of a scraped list of third-party addresses is the one to resolve first, and the answer is not in this repository. ## Why an hourly refresh beats a curated list for this use It is worth being clear about what freshness buys and what it costs, because a resolver list is not a static resource. Public resolver addresses get blocked, throttled, retired or reconfigured by their operators, and a list compiled by hand goes stale in exactly the way that hurts: it keeps working most of the time and fails on the runs that matter. Rebuilding from a published candidate list every hour means the file reflects what answered in the last hour rather than what answered whenever somebody last edited it, which is why the design leans on automation instead of curation. The cost is that you lose the attributes a curated list could carry. A hand-maintained list can note that one resolver is fast from a particular region, another is aggressive about NXDOMAIN, and a third is a sinkhole. This one cannot, because validation records liveness and nothing else, so the ranking work is pushed onto whatever tool consumes the file. ## A one-file dependency with no upstream version pinning The practical integration is a fetch of two URLs and a line count, which is both the appeal and the risk. There is no client library, no API, no schema and no release channel, so nothing here can break your build in the way a dependency upgrade does, and equally nothing will tell you that a file you cached three weeks ago has gone stale. The two files are separate addresses rather than one combined list, so a tool that cannot filter by family needs both and has to handle the case where one is empty. Because the pipeline depends on a third-party validator and a third-party candidate list, both of which can change or disappear without notice, the failure mode is a repository that keeps its hourly commits but suddenly contains a much shorter list, or an empty one. A consumer that checks length and freshness on each fetch will catch that; a consumer that assumes a successful clone means usable data will not. Nothing in the repository documents a schema beyond the file names themselves, so treat the format as newline-separated addresses and verify it before each run. ## Conclusion Fresh-Resolvers is a good fit for subdomain enumeration work where a stale resolver list is the bottleneck, since the whole point of the repository is that the file is replaced hourly rather than accumulating addresses that stopped answering. It is not a resolver service, not a configuration file for your own machine, and not a list you should route your own traffic through, because nothing in it is annotated with latency, location, or whether it resolves anything other than the query you fed it. Before depending on it, check two things: that the last commit is within the hour, since the project itself asks you to report a DM if the list has not been refreshed for more than a day, and that the licence is acceptable, because the repository declares none and the underlying validator and source list are separate projects with their own terms. The default branch is master and there are no tagged releases, so pin by commit. ## FAQ ### What is Fresh-Resolvers and what does it contain? It is a list of valid public DNS resolvers in two plain text files at the repository root, resolvers.txt and resolvers.ipv6, split by address family. The list is rebuilt on an hourly basis from the nameservers published at public-dns.info. ### How are the resolvers in Fresh-Resolvers validated? They are run through the DNS Validator project, which is credited to two named creators in the README. The validator is what filters the scraped candidate list down to resolvers that answer, and the filtered result is pushed to the repository hourly. ### Which tools can use the Fresh-Resolvers list? The README names shuffledns, massdns and zdns as tools that make use of resolver lists, and describes this one as consumable by them. All three read a newline-separated file of addresses rather than a structured configuration. ### How do I know if the Fresh-Resolvers list is still being updated? Check the commit history, since the project asks you to send the maintainer a direct message on Twitter if the list has not been updated for more than a day. There are no tagged releases, so the commit history on the master branch is the health signal. ### Does the Fresh-Resolvers list say anything about resolver speed or location? No. The entries are plain addresses with no metadata about response time, country, or resolver type, and the validation step records whether a resolver answered rather than what it is good for. Ranking and filtering are left to the tool that consumes the file. ### What licence applies to the Fresh-Resolvers data? The repository declares no licence for its contents, even though the underlying candidate list and the validator are separate projects with their own terms. For redistribution or commercial use, the permission question needs resolving separately. ## Sources - [Official README](https://github.com/proabiral/Fresh-Resolvers#readme) - [Project repository](https://github.com/proabiral/Fresh-Resolvers) - [README](https://github.com/proabiral/Fresh-Resolvers/blob/master/README.md) - [Releases](https://github.com/proabiral/Fresh-Resolvers/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/proabiral-fresh-resolvers