https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...
The list is not so much interesting for the options that it presents, as far as I am concerned, but for the things that it reveals. Every single entry that is explicitly marked 'China' also has 'operates under Chinese regulations'; which is, in 2026, something that is of concern for more than just the Chinese entries on the list, to people on my continent for starters.
'Run by one individual in Denmark.' is an interesting statement of bus factor, but I don't think that all of the other entries should be assumed to be better just because they are mute on the point. There's far less information about who is behind DNS.Watch than there is about Thomas Steen Rasmussen. And it appears that DNS.Watch went off the air at least once in recent years, so it is a legitimate concern.
Then there are all sorts of things not on this list that might matter to people, such as Quad101 looking like it has geographic restrictions on whom it is available to and Gcore being an AI company.
Many public wifi network works need you to use their DNS, so they can redirect you to a gated "accept ToS" screen (and may even require re-approval every 30-60 minutes).
To resolve the issue is so frustrating:
1. realize the internet stopped working 2. ping google.com, wait for timeouts to show up. 3. try to guess if its a ISP issue, but then realize the wifi probably timed out. 4. Switch the dns. Flush DNS. 5. try to access a non-TLS domain 6. approve the gate 7. switch the DNS back
There has to be something that manages this
I pre-cache all the domains I use hourly via cron. My ISP is not going to dork with my DNS requests and their employees are bigger deviants than I. If I ever started browsing the web from a phone I would just set up my own public DoH server. It only takes a few minutes and gives me my own query logs for debugging weird issues.
[1] - https://tls-ech.dev/
Plus it’s reliable and fast from basically anywhere (which is harder to achieve if I ran my own resolvers in the cloud, and anyway I don’t want to have to maintain that).
Imagine seeing response times at P90 for a series of random lookups and comparing the median response times.
Some like cloudflare doesn’t support that in the name of privacy.
EDNS lets the dns server of the site you are visiting know from where you are connecting and can give you the closest server. 1.1.1.1 does not do that. This breaks all sorts of ISP cache and peering arrangements.
Here’s an example: My ISP’s google global cache is broken every time I use cloudflare. With google dns, opendns, isp’s own dns I get my ISP’s own ip address for the domain “googlevideo.com” which is where youtube videos load from. With cloudflare dns I get an ip address of an actual google server which may or may not be in my country. Result: my downloads from google drive/youtube/play store all are faster with a dns server with proper EDNS support.
Now imagine this on a global scale for smaller websites, your request might go to a different continent.
I understand the product decision for cloudflare and I don’t want them to change but this is something people should know about. There are numerous reports on their forums which are always locked with no activity.
I am not saying it’s a conspiracy but this doesn’t affect sites on cloudflare btw due to their global anycast routing/infra setup which I don’t know enough to explain.
Even if it's configuring something for boomer family, that sounds like a recipe for "why is this website not working"?
I find it more interesting as a statement about organizational oversight. If there are multiple people involved in operations, they can keep an eye on each other and speak up if they see anything weird going on (e.g. a DNS resolver implementing selective logging or interfering with results). If there's only one person running the show, there's no one to call them out.
(And if you're thinking, "but so-and-so is a principled person, they would never do anything like that" - pressure from law enforcement can be a powerful thing.)
That’s what I’ve been using for years and never had any issues with public hotspots.
All the big DNS servers are in the 5-6ms range for me, but that hasn’t always been the case. My ISPs DNS is about the same but with crazy variance and spikes of up to 50ms, even though they should be able to be the fastest.
But yes, then you happen upon your first false positive.
And you switch back to a non filtered DNS OR one that you can whitelist or control, still annoying.
sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
I did this for an internal website at my university that could only be resolved using the network name server. It just occurred to me that it might also work for the URL macOS uses to detect captive portals. We'll have to see if it works the next time I'm at a café.How does this look? Shell script querying a list of hostnames? What qualifies as a domain you use?
echo "nameserver 192.168.1.1" | sudo tee /etc/resolver/captive.apple.com[1] - https://nochan.net/b/Internet-Crap/20260602-Set-Up-Your-Own-...
Once Quad9 blocked Halo MCC XBOX Live -> Steam achievements, several fileshare services (probably used for malware somewhere but not my usage) etc...
1.1.1.1 blocked archive.is or got blocked by them or something...
Gone back to Google DNS (gasp) for now, yes as a European... no blocking, fast, never goes down.
If you have knowledge of TCP, you know you will occasionally get stalls much greater than that beyond control.
If it is this hard to choose a resolver, imagine how hard it is to choose a web browser, which is a choice that actually matters.
The nearest resolver is
$ sudo apt-get install unbound
and now your own host is your resolver. The complexity of this is roughly a millionth of a percent of that of your web browser.The good thing about dnsdist is that it acts as a sort of load balancer for DNS queries and offers features such as dynamic blocking (including via eBpf) at the IP level and rules and rate limits for query types you can combine. Therefore, there are no limits (or very open limits) for all query types from whitelisted IPs, and stricter rules for all others. IPset and GeoIP banning of known malicious IPs and regions (using block-lists) also keeps the footprint of "unwanted" use very, very small.
Unfortunately, if the CDN only rely on BGP steering (or conversely if you are a user who is stuck on an ISP monopoly), there are cases where this is not necessarily the nearest network-wise (or performant network-wise) if there are peering disputes. If the said ISP is a virtual monopoly or (worse) state-sanctioned to collect network "toll fees" (like in South Korea), non-preferred and international routes are (intentionally) congested.*
If you use a third-party DNS, you basically lose this DNS optimization, and ECS does not fully solve this (because sometimes the DNS override are placed only on the ISP's recursive DNS servers). You're basically in a lose-lose position: either use third-party servers and the IP addresses served to you on popular CDNs are in the congested path, or use the often-unreliable and heavily-logged ISP-provided DNS.
* Usually. There are exceptions, but this comment is just a simplification of the complexities of real-life networking (where RFCs and mutual cooperation die out without fanfare).
Edit for further reading: DNS is the new BGP by Geoff Huston of APNIC (https://ispcol.potaroo.net/2023-09/service-routing.html), How LinkedIn used PoPs and RUM to make dynamic content download 25% faster from the old LinkedIn engineering team (Archived at https://web.archive.org/web/20160310065302/https://engineeri...), Wikimedia's mapping of their CDNs (https://gerrit.wikimedia.org/r/plugins/gitiles/operations/dn...)
Is the author suggesting this represents the actual number of open resolvers on today's internet
How can any consideration of "privacy" or "security" of DNS not also consider SNI
SNI allows third parties to see when the user tries to connect to an address published for a domain name. It can allow third parties to interfere with such connections
DNS only allows third parties to see when a user looks up an address published for a domain name. To associate non-DNS traffic with these queries requires assumptions about the software that is sending them
Hence it is not surprising the advertising companies that control the popular web browsers want users to choose DoH _within the browser_ or corporate OS, deceptively labeled as "private DNS"^1, so these third parties can more effectively correlate these queries with non-DNS traffic from browsers or software running on corporate OS
1. Perhaps these companies will be sued for these deceptive claims. For example, users have successfully sued for deceptive claims about "private browsing"
ISP: 1ms to Cloudflare
Cloudflare: 10ms to Cloudflare
Thank you for your attention to this matter.
Edit: will clarify, this advice applies to countries with good privacy laws and no national surveillance i.e. not the USA
https://www.cira.ca/en/canadian-shield/configure/summary-cir...
It would need to be built into iOS/Android/Linux/Windows/MacOS but what would be the disadvantages?
I can see greater load on root servers but caching is specifically designed to reduce that.
I can see potential problems for CDNs and equivalent geo-based resolvers.
But are they really that bad?
note on privacy: if you are using port 53 you are cooked so make sure you are using dns-over-tls or dns-over-https.
I would suspect some of non-optimized scenarios are eyeball network operator decisions on their networks that DNS providers and others do not have much control over. Like, Cloudflare resolves an IP that is closest to them, which is likely also the closest to the end user (and the eyeball ISP), but the eyeball ISP BGP path to that resolved IP takes a roundabout path because of their own BGP policy because $reasons.
For the long tail of unknown open DNS resolvers, use Shodan. But I would not suggest that you use any findings from Shodan to trust your internet usage with.
Yes, SNI is a generic internet privacy problem. However, it is not a property of DNS. On the positive side, ECH has been pushed through the IETF and should slowly be available to the general user.
/ The author
It's just a "me" thing. Others can and should do whatever they think will work for them. If everyone does this a little different that is probably best.
Had me in stiches
localroot.isi.edu
Bias: I created it, and am a author of one potential set of future specifications (rewrite).
What is the primary difference between using an Unbound auth-zone (as described in the RFC) compared to localroot?
Your DNS traffic to Cloudflare is routed via anycast. If Cloudflare is sending this DNS query (eg to an authoritative DNS server), the IP address it uses for this is not going to be the anycast one. These IPs are geolocatable and Cloudflare even publishes feeds of their approximate location. The response you get will be geolocated based on the IP that Cloudflare is using to send traffic to the authoritative.
Cloudflare explicitly does not use ECS (the edns extension to provide client subnets to authoritatives): https://developers.cloudflare.com/1.1.1.1/faq/#does-1111-sen...
DNS Resolver Guide
Independent reference
Pick what matters to you, such as privacy, malware blocking, parental controls, speed, IPv6, or a specific jurisdiction, and the finder narrows 29 global public resolvers to the ones that fit. A full comparison table and research-backed decision notes follow.
29public resolvers
15jurisdictions
DoH / DoT / DoQencrypted transports
12studies cited
Step 1 · Interactive finder
Check what matters to you. Transport, DNSSEC, IPv6, jurisdiction and operator type are hard filters. The priorities are scored and ranked.
Maximum privacy and no loggingMinimal or no query logging, privacy-first operator Block malware and phishingSecurity blocklist on by default or via a simple variant Block ads and trackersNetwork-wide ad and tracker filtering Parental controls and adult-content blockingFamily or adult-content filter available No filtering (unaltered DNS)Returns answers exactly as published Fully customizable filteringChoose your own blocklists or rules via an account Top-tier speed (global anycast)Large low-latency anycast network Non-commercial operatorNonprofit, registry, community or public-interest, not a for-profit company
DNS-over-HTTPS (DoH) DNS-over-TLS (DoT) DNS-over-QUIC (DoQ) DNSCrypt
Must validate DNSSEC Must offer IPv6Provides IPv6 resolver addresses Operator jurisdiction Operator type EDNS Client Subnet (ECS)
Step 2 · Live latency test
This measures DNS-over-HTTPS round-trip time from your browser to each DoH-capable resolver, so you can see which is fastest where you actually are. Plain-DNS-only resolvers cannot be tested this way. Results are a relative guide and include TLS and HTTP overhead, so run it a couple of times. Your browser queries each resolver directly, which reveals your IP address to them; nothing is sent anywhere else.
Benchmarks the DoH-capable resolvers, takes a few seconds.
| # | Resolver | Median | Latency | Best |
|---|---|---|---|---|
| Press Run to benchmark from your location. |
Technique inspired by the open-source DNS Speed Test by Silviu Stroe (GPL-3.0); this is an independent implementation. It runs only when this page is served over HTTPS. For resolvers not testable here, that dedicated tool benchmarks a wider DoH set.
Step 3 · Full comparison
Click a column header to sort. Search by name, operator, jurisdiction, or feature. Filter-variant addresses (malware, family, unfiltered) are listed in the Filtering cell.
| Resolver | Jurisdiction | Type | Primary IPs (v4 / v6) | Filtering (default and variants) | DNSSEC | Transports | Logging | ECS |
|---|
Evidence
Findings from peer-reviewed DNS measurement studies that should shape the trade-offs above.
Encrypted transports (DoH and DoT) add latency per query, yet whole-page load times are often close to plain DNS, and DoH's overhead is small in practice. On lossy or high-latency links, plain Do53 still wins. Performance also varies by provider and region, so the fastest resolver depends on where you are.
Hounsel et al., WWW 2020; Böttger et al., IMC 2019; Chhabra et al., IMC 2021.
The largest end-to-end study of encrypted DNS found queries are far less likely to be intercepted or altered in transit than plain DNS, with only minor overhead. Operator quality varies, though: about 25% of DoT providers in that study served invalid TLS certificates, so favour well-run providers.
Lu et al., IMC 2019.
Whichever provider you choose still sees every domain you look up. If that worries you, prefer no-logging operators, or an oblivious design (ODoH) where a proxy separates your identity from your queries so no single party sees both. Cloudflare and Apple have deployed ODoH.
Schmitt, Edmundson & Feamster, PoPETS 2019; Singanamalla et al., 2021.
Only a validating resolver protects you from spoofed records. Google, Cloudflare and Quad9 all validate, and they handled the first root-key (KSK) rollover without breaking users. If integrity matters, treat DNSSEC validation as a must.
Müller et al., IMC 2019.
EDNS Client Subnet sends part of your IP to CDNs for better geo-routing. Google and OpenDNS send it for sharper CDN mapping; Cloudflare and standard Quad9 leave it off for privacy. Pick based on which you value more.
"A Look at the ECS Behavior of DNS Resolvers", IMC 2019.
The operator's legal home governs what can be compelled or logged, and a handful of providers now carry a large share of the world's recursive traffic. The U.S. NSA has also warned that external resolvers bypass internal DNS filtering and inspection, so weigh control against convenience.
Moura et al., IMC 2020; NSA guidance, 2021.
A 2022 measurement of DoQ found it already beats both DoT and DoH on response time, though about 40% of handshakes were slowed by QUIC's address-validation limit. Where your client and resolver both support it (Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS, and the Chinese majors here), DoQ is the encrypted option to prefer.
Kosek et al., PAM 2022.
DNSCrypt predates DoH, DoT, and DoQ (version 2 dates to 2013). It encrypts from the first packet using a resolver's pre-shared public key, so there is no plaintext hostname lookup and no dependency on certificate authorities, and its Anonymized DNS mode (2019) also hides client IPs. Among the resolvers here it is offered by Quad9, OpenDNS, AdGuard, NextDNS, Control D, and Yandex. Reliable usage numbers are scarce, though: population-scale measurements such as APNIC Labs track DoH and DoT but not DNSCrypt, so there is no trustworthy public figure for how many people use it.
DNSCrypt Project; APNIC Labs encrypted-DNS measurement.
Even over DoH, traffic analysis can identify the domains you visit with high accuracy, and the standard EDNS padding does not fully prevent it. If that threat model applies to you, pair encrypted DNS with Tor or an oblivious design rather than relying on padding.
Siby et al., NDSS 2020.
A 2023 study of Extended DNS Errors across major resolvers found they disagreed on diagnostic error reporting in 94% of test cases, with Cloudflare the most precise. Implementation quality and standards compliance differ between providers, which affects troubleshooting and reliability.
Nosyk, Korczyński & Duda, IMC 2023.
References
Smaller, community-run, and regional resolvers
Niche, hobby, community, or country-specific services that are not in the comparison above. Worth knowing about, but check their current status and policies before relying on them. The European entries are catalogued by European Alternatives. Resolvers based in heavily censored or sanctioned regions may enforce local content rules or, conversely, exist mainly to bypass geo-blocks, so treat those with extra care.
* for the countries/ISPs that don't also hijack all DNS
https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...