DNSCrypt/dnscrypt-resolvers for Public DNS Lists

What DNSCrypt/dnscrypt-resolvers Contains

DNSCrypt/dnscrypt-resolvers addresses a configuration problem in encrypted DNS environments. A user or software project may know that it wants a DNSCrypt resolver, a DNS-over-HTTPS resolver, an oblivious DoH service, or a relay, but still lack a current, centrally published list of public endpoints and their associated metadata. This repository collects those service lists and related subsets. The README identifies the main resource as an interactive list of public DNS servers and separately points to a relay list, an ODoH server list, and an ODoH relay list. That separation matters because the transport type and the role of the endpoint are different concepts. A server answers DNS requests, while a relay forwards traffic. The repository therefore supports more than one deployment model for encrypted DNS.

The project is primarily aimed at people configuring dnscrypt-proxy-like software, researching public encrypted DNS endpoints, or building tools that consume resolver metadata. The repository description says it has been actively maintained since 2011, but the repository has no GitHub releases. The relevant maintenance signal is instead its Git activity: the last push was on 2026-10-16. The project is not marked as archived. That indicates an active repository history, but the README does not promise a fixed release cadence, compatibility policy, or service-level agreement for listed DNS endpoints.

Repository Structure and List Generation

Based on the repository layout, the project is organized around versioned data and supporting utilities rather than around a single server binary. The `v3/` directory is the location named by the README for stable downloads. It contains the public resolver material and the relay and ODoH documents. Older `v1/` and `v2/` directories also exist, while `www/` appears to contain the web-facing project area. The repository is primarily Go according to the repository metadata, but the visible Makefile shows that the data workflow is driven by scripts and text generation.

The Makefile defines a repeatable `all` target. It runs `./utils/format.py`, generates `v3/opennic.md` from `v3/opennic.subset` and `v3/public-resolvers.md`, then generates `v3/parental-control.md` from `v3/parental-control.subset` and `v3/public-resolvers.md`. It moves each generated file into place and runs the formatter again. A separate `clean` target removes backup files matching `*/*~`. This is a concrete distinction from a hand-maintained list repository. Subsets can be derived from the main resolver list, with topic-specific views generated into dedicated Markdown files.

The README also publishes a Minisign public key:

RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3

That key is intended for verification workflows associated with the published lists. The README does not provide the exact command for using it, so an integrator should consult the contribution or verification documentation before assuming a particular Minisign invocation.

Stable Download and First Integration Path

The README does not present this repository as a package with installation commands, and it does not document a `go install` step. Its stated distribution method is direct access to stable v3 downloads. For a first use, read the `v3/` directory or retrieve a stable file from the download location named by the README, then inspect the entries relevant to the DNS transport you intend to use.

The repository provides these stable locations:

https://github.com/DNSCrypt/dnscrypt-resolvers/tree/master/v3
https://download.dnscrypt.info/dnscrypt-resolvers/v3/

The relay and ODoH documents have their own GitHub and download URLs. Those files are not merely editorial links if your client needs relay or ODoH configuration data. The README specifically identifies `relays.md`, `odoh-servers.md`, and `odoh-relays.md` under `v3/`.

For contributors rather than consumers, the Makefile provides the documented generation path. After checking out the repository and changing the source or subset files, invoke its `all` target. This runs the formatter and generates the OpenNIC and parental-control Markdown subsets. The README directs contributors to `CONTRIBUTING.md` for the rules for updating existing services or adding new ones. The repository does not document a production deployment recipe, so do not infer that `make all` is required to consume the published lists.

What DNSCrypt, DoH, ODoH, and Relays Mean Here

The repository separates four categories in its published resources: public DNSCrypt servers, public DoH servers, ODoH servers and relays, and anonymized DNS relays. The README uses the term “Oblivious DoH” for ODoH and describes separate server and relay lists. It also links to a DNSCrypt relay list. The categories are useful because they answer different configuration questions. A DNSCrypt-enabled resolver is relevant to clients that support DNSCrypt. DoH entries serve DNS over HTTPS clients. ODoH entries describe a distinct oblivious configuration. Relay entries describe intermediaries rather than authoritative answering services.

This arrangement does not make a resolver private by itself. The repository lists public services and relays, but the README does not document the logging policy, jurisdiction, ownership, uptime, filtering behavior, or cryptographic configuration of every endpoint. Nor does it state that every entry is suitable for every client. The interactive list and public status page are separate resources, so users should treat the static repository data and service health as related but different concerns.

The repository also points to more DNS server sources through the DNSCrypt Proxy wiki. That is an explicit alternative source of discovery, but the project itself remains focused on public lists and relays. It is not documented as a recursive resolver implementation, a local caching proxy, or a replacement for `dnscrypt-proxy`.

Validation and Operational Boundaries

The largest limitation is that a directory of public endpoints cannot itself guarantee that an endpoint is reachable, trustworthy, or appropriate for a particular deployment. The README provides a public status page, but it does not define how status is calculated or whether it covers every service in the static files. It also does not claim that listed endpoints have consistent availability or that their operators accept automated consumers. Endpoint validation remains an integration concern.

The data is published through stable URLs, but the README does not describe rollback, version retention, schema compatibility, or a formal policy for removing stale entries. The repository has no GitHub releases, so consumers should not assume that release notes will describe list changes. The last push date indicates repository activity, not a guarantee that each DNS service was checked on that date.

For organizations with strict network requirements, the list should be treated as input to policy enforcement rather than as an allowlist by itself. The README does not specify fields for geolocation, ownership, retention, filtering, or compliance classification. If those attributes matter, they must be verified against the endpoint operator or another documented source.

DNSCrypt/dnscrypt-resolvers Versus Other DNS Discovery Sources

A direct alternative is to configure endpoints from the provider’s own documentation or from an internal inventory. That approach requires selecting endpoints manually, but it can provide deployment-specific information that a general public list does not claim to cover. For example, an internal inventory can record which endpoints are approved for a particular network. The README does not document those attributes for the public list, so this is a difference in workflow, not a claim about any particular provider.

Another alternative is the DNSCrypt Proxy wiki’s DNS server sources page, which the README links under “More DNS server sources.” That page is a broader discovery route, while `dnscrypt-resolvers` presents versioned public-server, relay, and ODoH documents. The repository’s generated subsets also support narrower views such as OpenNIC and parental control. Choosing between them depends on whether the main requirement is a broad public list, a relay-aware configuration, or an internally controlled set of endpoints.

Editorial conclusion

Adopt this repository when you need a maintained source of public DNSCrypt, DoH, ODoH, or relay entries. Do not treat it as a resolver client or assume that every listed endpoint meets your privacy, availability, jurisdiction, or reliability requirements. Verify the v3 data format, endpoint metadata, current service status, and the signing key before integrating the lists into an automated system.

Frequently asked questions

Official sources

1. DNSCrypt/dnscrypt-resolvers on GitHub
2. Issues
3. Project website
4. README