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.
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.)
As a concrete thought experiment, consider if (say) a WWW/DNS hosting company providing such free proxy DNS service decided to covertly record the domain name lookups from the general public that fail in order to compile a list of domain names for the company to prospectively squat on. Having multiple employees handling the public service doesn't stop this if it is the company's actual business decision to sneakily do this.
It really is a statement of bus factor, not about oversight. To make a statement about oversight one has to take into account something else not covered by this list: which of the list entries has attempted to show some level of independent auditing or oversight of its data protection.
* https://blog.cloudflare.com/announcing-the-results-of-the-1-...
CloudFlare has had some independent auditing done, by an accountancy firm. DNS4EU holds itself subject to GDPR rules on Personal Data with respect to query data, and so is auditable by the Czech ÚOOÚ. AdGuard likewise, except that it holds Personal Data in Frankfurt. CZ.NIC likewise, except that it hasn't actually updated its legal doco since 2018 and it's only by implication that the Czech ÚOOÚ can audit the Personal Data handling under the GDPR. DNS.SB simply disclaims the existence of any Personal Data whatsoever, which as with AdGuard is overseen by the German BfDI and relevant Land authorities (HBDI for Frankfurt).
* https://legal-documents-dns4eu.s3.fr-par.scw.cloud/DNS4EU-Pu...
* https://adguard-dns.io/en/privacy.html
* https://nic.cz/files/documents/20180525_Zasady_zpracovani_os...
* https://bfdi.bund.de/EN/Home/home_node.html
* https://datenschutz.hessen.de
Even Thomas Steen Rasmussen, who also claims zero Personal Data, would be subject to oversight by the Datatilsynet.
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
* for the countries/ISPs that don't also hijack all DNS
https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...
Had me in stiches
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...
https://www.cira.ca/en/canadian-shield/configure/summary-cir...
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
sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
Captive.apple.com resolves to captive portal domain
Captive portal domain fails to resolve because the portal is private and Google DNS doesn’t know about it.
Might work for captive portals that Google can resolve though?
echo "nameserver 192.168.1.1" | sudo tee /etc/resolver/captive.apple.comThat’s what I’ve been using for years and never had any issues with public hotspots.
I think if I force the dns this way, the public dns won’t resolve the captive portal.
When the internet is cut, it needs to use the network’s dns to resolve the captive portal domain (whatever that is)
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).
Yup, same here, especially after hears of messing around with a pihole and got tired of maintaining it. Also, NextDNS works easily with Mullvad VPN, when needed.
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/
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.
Nothing prevents the ISP from collecting that.
I know some (all?) EU advertisers deny creatives based on optics i.e. "our name and logo is on the billboard frame, we don't wanna get associated with topic X".
And I've got a little tool that takes:
ayt7.ads.acme.com
afi6.ads.acme.com
foi5.ads.acme.com
ads.acme.com
mybank.com (legit)
myb4nk.com
mibank.com
mybank.{any other tld}
I generate hundreds of thousands of such variations: all blacklisted by unbound.
I did it after one of my bank sent me an example of a very convincing phishing site.
Been using such a setup since years now. A million blocklisted domains runs fine on an old Pi 3. I take it that on a more powerful computer unbound can deal with blocklist with millions if not tens of millions of domains (and, no, I haven't moved to whitelisting only).
I also block all unicode domains. I simply cannot access a domain name that use unicode characters in its name (and, no, I don't care).
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.
How does this look? Shell script querying a list of hostnames? What qualifies as a domain you use?
[1] - https://nochan.net/b/Internet-Crap/20260602-Set-Up-Your-Own-...
https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...
I also used third-party public resolvers before. Mainly FFM (its not on the list) but non-profit, EU and encrypted. If you boil down the list (from the website) to this categories, you have 4 providers. You can trust, in my opinion. But the problem with all this provider is, that you ran quick into rate limits or some query type restrictions. Especially if you run your own mail server or other DNS expensive task.
Fun fact about hosting your own DNS infrastructure and offering it to friends and family: They might actually trust other providers more than they trust you. Even if they know and trust you personally. Because they know you can theoretically read their queries, it’s more convenient for them to have a stranger do it instead.
Imagine seeing response times at P90 for a series of random lookups and comparing the median response times.
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.
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?
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?
[0]: https://quad9.net/service/service-addresses-and-features/
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
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.
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...)
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.
BGP's default route selection is to use the choice with the shortest AS Path.
If your ISP and your CDN peer in some locations, but not all, you can easily run into longer latency.
Ex: customer in Seattle, but ISP and CDN peer in Portland. CDN has a PoP in Seattle but not peered with the ISP.
BGP (without a lot of tuning) will prefer to send traffic through Portland, rather than through transit in Seattle, because the AS path through Portland is ISP -> CDN and the AS path in Seattle is ISP -> Transit ISP -> CDN
Of course, CDNs try to get peering in all common locations to address this, but that's not always possible, and not always because the ISP is unreasonably uncooperative. Sometimes the best path to resolution is by targetting the ISP dns server, but it doesn't catch all the customers.
Even if it's configuring something for boomer family, that sounds like a recipe for "why is this website not working"?
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.
I use a "block known malware and known porn sites" and then, on top of that, I use gigantic blocklists blocking known ads and trackers.
But then I've got a whitelist of allowed domains, which I updated on-the-go if that one site wife really needed wasn't working due to overzealous filtering.
The reason is simple: browsing with ads and trackers blocked at the DNS level feels not just a bit but much snappier (and there's not need to play cat and mouse with browsers' extensions). And privacy.
I've got a pretty advanced unbound DNS server, blocking ads, trackers, known porn, known malware and shitloads of homoglyph attacks.
Took some time to set up but after that it's smooth sailing. My old Pi 3 running unbound stays always on. The only time I turn it off is when I leave for vacation. It's just that stable.
Gen Xer here, not a boomer.
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.