HN Debrief

Choosing a Public DNS Resolver

  • Infrastructure
  • Privacy
  • Security
  • Networking
  • Open Source

The post is a buyer’s guide for public DNS resolvers. It compares 29 services across features people actually shop for now, including DNS over HTTPS and TLS, logging claims, filtering options, and the legal regime each operator sits under. That framing landed well, but the useful conclusion was narrower than the catalog suggests. Picking a resolver is not really about finding “the best DNS.” It is about choosing who gets to see your queries, whether you want filtering, whether you need to dodge ISP or state DNS tampering, and whether you are willing to trade some CDN locality for privacy.

Treat public DNS as a trust and networking decision, not a simple speed tweak. If you care about privacy, censorship resistance, or filtering, test resolvers from your own network and decide whether a managed service like NextDNS or a self-hosted resolver gives you the control you actually need.

Discussion mood

Engaged and pragmatic. People liked having a structured resolver comparison, but the dominant mood was skeptical of one-size-fits-all recommendations and especially of simplistic privacy claims. The comments kept dragging the topic back to first principles: who you trust, whether you should self-host, how much CDN performance you are willing to give up, and whether filtering will break things you care about.

Key insights

  1. 01

    Audits matter more than headcount

    A resolver run by one person has bus-factor risk, but a resolver run by many employees is not automatically safer. Corporate abuse usually happens through normal management channels, not because a rogue operator went off script. The better signal is whether anyone has subjected the service to outside scrutiny or legal accountability. Cloudflare’s published privacy audit and EU-based services that fall under GDPR oversight were cited as stronger evidence than vague claims about being privacy friendly.

    When you evaluate a resolver, look for independent audits, privacy policies with specifics, and a regulator that can actually compel answers. Treat anonymous ownership and hand-wavy trust language as risk, even if the service is popular.

      Attribution:
    • JdeBP #1 #2
    • duskwuff #1
  2. 02

    CDN locality depends on resolver behavior

    The fastest resolver is not the one with the lowest query latency. It is the one that helps large content networks send you to a good cache node. Services like Akamai, Netflix, YouTube, and some ISP caches still depend on DNS-based steering, and Cloudflare’s choice not to send EDNS Client Subnet can produce noticeably worse paths in some networks. Anycast on its own does not remove this issue, because the recursive resolver still reaches authoritative servers from its own infrastructure and those answers can be geotargeted differently.

    Benchmark streaming, downloads, and app behavior, not just DNS lookup time. If your users depend on CDN-heavy traffic, test at least one privacy-focused resolver and one ISP-friendly or ECS-capable resolver from the same connection.

      Attribution:
    • ratorx #1
    • vimda #1
    • adithyassekhar #1
    • amaccuish #1
    • progval #1
    • zinekeller #1
  3. 03

    Encrypted DNS helps before ECH arrives

    The useful correction on privacy was that DoH and DoT already hide DNS lookups from passive observation by your ISP, even if they do not solve everything. SNI still leaks destination names on many connections, and ECH deployment is real but not yet broad enough to erase that gap. Calling encrypted DNS worthless until ECH is universal misses the immediate benefit. It narrows exposure today, especially where ISPs are not doing full-scale deep packet inspection.

    Turn on DoH or DoT if your platform supports it, but do not sell it internally as full browsing privacy. If destination confidentiality matters, track ECH support in your browsers, CDNs, and reverse proxies as a separate rollout question.

      Attribution:
    • tredre3 #1
    • marginalia_nu #1
    • llm_nerd #1
    • miniBill #1
    • ekr____ #1
  4. 04

    Self-hosting changes who you trust

    Running your own recursive resolver gives you control over policy, logging, blocklists, and reliability. It does not magically make DNS private. Direct recursive lookups still traverse your ISP unless you tunnel them to a remote endpoint you control or to a third party. That leaves you with a more honest framing: self-hosting is mostly about control and independence, while privacy still depends on what network path you choose upstream.

    If you self-host, decide separately whether you want local recursion, an encrypted upstream, or your own remote public resolver. Write that choice down as an explicit trust decision instead of assuming self-hosting solved privacy by itself.

      Attribution:
    • exiguus #1 #2 #3
  5. 05

    Filtered resolvers fail in annoying ways

    The appeal of malware and ad blocking at the resolver layer is obvious, but false positives and opaque failures are common enough to shape provider choice. Quad9 was praised, then immediately hit with examples of blacklist mistakes and confusion over endpoint features. Cloudflare’s normal resolver was defended as unfiltered, yet people still reported real-world failures and archive.today oddities that are indistinguishable from censorship when you are the end user. Reliability is not just uptime. It is also whether the resolver surprises you with policy.

    Use filtered DNS only if you can switch profiles easily or maintain a whitelist. For businesses and less technical households, an unfiltered default plus optional filtering is usually easier to support than blanket blocking.

      Attribution:
    • mzajc #1
    • johnhtodd #1
    • Scroll_Swe #1 #2
    • jaychandra68 #1
    • degenerate #1
    • chopin #1

Against the grain

  1. 01

    ISP DNS can be the right performance choice

    Using your ISP’s resolver was defended on network engineering grounds, not brand loyalty. In some regions the ISP resolver gives the shortest path to ISP-hosted caches and better CDN placement than generic public DNS. The same comment paired that with local filtering on a router like UniFi, which keeps ad blocking on-net while preserving the ISP’s topology advantages upstream.

    If your priority is video, downloads, or app-store performance on a specific ISP, do not assume public DNS is better. Try local filtering with the ISP resolver as upstream before you accept a permanent performance penalty.

      Attribution:
    • aetherspawn #1 #2 #3
  2. 02

    Public resolver shopping misses the local-first option

    One commenter rejected the whole premise of comparing public resolvers as if that were the main privacy decision. Their setup keeps bulk DNS data locally and avoids remote lookups during ordinary web access, which makes resolver choice mostly irrelevant for them. That is an edge case, but it usefully punctures the assumption that everyone should optimize around a third-party recursive service.

    If DNS is mission-critical in your environment, consider whether local data, forward proxies, or other architecture changes can remove dependency on public recursive DNS altogether. Resolver comparison sites are most useful when you accept the premise of remote DNS in the first place.

      Attribution:
    • 1vuio0pswjnm7 #1 #2

In plain english

AdGuard Home
A self-hosted network-wide DNS filtering and blocking service for ads, trackers, and malicious domains.
anycast
A routing technique where many servers share the same IP address and the network sends users to a nearby instance.
CDN
Content Delivery Network, a distributed system of servers that delivers content from locations closer to users for speed and reliability.
DNS
Domain Name System, the internet service that turns domain names like example.com into IP addresses computers use to connect.
dnsdist
A DNS load balancer and traffic management tool often paired with recursive or authoritative DNS servers.
dnsmasq
A lightweight DNS forwarder and DHCP server often used on routers and small networks.
DoH
DNS over HTTPS, a way to send DNS requests inside encrypted web traffic so they are harder for networks in the middle to read or tamper with.
DoQ
DNS over QUIC, a newer encrypted DNS transport that uses the QUIC network protocol.
DoT
DNS over TLS, a way to send DNS requests over an encrypted Transport Layer Security connection.
ECH
Encrypted Client Hello, a TLS feature designed to hide information like SNI so observers cannot easily see the destination hostname.
ECS
EDNS Client Subnet, the DNS extension used to expose part of the client’s network location for traffic steering.
EDNS Client Subnet
An extension to DNS that lets a recursive resolver send part of the user’s network location to authoritative servers so they can return a nearby CDN endpoint.
GDPR
General Data Protection Regulation, the European Union’s main privacy law governing how personal data can be collected and used.
Pi-hole
A popular self-hosted DNS filtering tool commonly used to block ads and trackers on home networks.
SNI
Server Name Indication, a field sent during many TLS connections that can reveal which hostname a user is connecting to.
Unbound
An open source recursive DNS resolver often used for self-hosted local DNS caching and validation.

Reference links

Resolver privacy and policy documents

Regulators and oversight bodies

Benchmarks and tooling

Protocol references and technical background

CDN routing and DNS steering

Resolver services and setup references