Choosing a Public DNS Resolver

Original Article ↗ Hacker News Discussion ↗

Choosing a DNS resolver turns out to be less about raw speed and more about whom you trust with your traffic and what trade‑offs you accept. Commenters weigh public options like Quad9, Cloudflare, Google, NextDNS and ISP DNS against running their own recursive resolvers (e.g., Unbound, AdGuard Home), debating privacy, logging, censorship circumvention, EDNS client subnet effects on CDN performance, and the reliability of malware/ad‑blocking features. A recurring theme is that there is no universally “best” resolver: encrypted DNS (DoH/DoT), local caching, and custom blocklists can improve privacy and control, but they introduce complexity, occasional breakage, and dependence on specific networks or operators.

Public Resolver Choices

  • Many favor Quad9 (9.9.9.9) or Cloudflare (1.1.1.1); some combine Quad9 primary with Cloudflare or Google (8.8.8.8) as fallback.
  • Quad9: praised for privacy and DNSSEC support on all endpoints, but criticized for malware-blocking false positives (e.g., trackers, file-sharing, even large sites).
  • Cloudflare: seen as fast and robust; criticisms include occasional failures (NXDOMAIN on valid domains), lack of EDNS client subnet (ECS), and concerns about US surveillance laws.
  • Google DNS: used despite privacy reservations because it’s “fast, no blocking, never goes down” in some regions.
  • Other options mentioned positively: NextDNS (high configurability, integrates with VPNs), DNScrypt resolvers, regional services like Canadian Shield.

Self-Hosted Resolvers

  • Strong contingent runs local recursive resolvers (Unbound, PowerDNS/dnsdist, AdGuard Home, dnsmasq) for privacy, control, and reliability.
  • Techniques include:
    • DNS over HTTPS/TLS/QUIC frontends.
    • Heavy caching, prefetch, and “serve-expired” to survive upstream outages.
    • Pre-caching top domains via cron; some even intentionally generate “noise” traffic.
    • Large local blocklists for ads, trackers, malware, phishing variants, and homoglyph/unicode domains.
  • Downsides noted: more uncached queries (slower first lookups), root/authoritative traffic load, complexity, and lack of encryption to root servers unless tunneling via DoH/DoT/DoQ or VPN/Tor.

Ad/Malware Blocking Tradeoffs

  • DNS-level ad/malware blocking is valued for speed, reduced clutter, and privacy, especially on mobile apps.
  • Repeated concern about false positives breaking sites, games, or file-sharing; some revert to non-filtered DNS or insist on resolvers where they can manage allowlists.

Performance, ECS, and CDNs

  • ECS support is highlighted as a missing but important dimension: without it, users may be routed to distant CDN nodes (slower YouTube/Google downloads, etc.).
  • Some argue ISP DNS often gives best CDN locality; others prefer third-party DNS plus local caching and ad-blocking.
  • Anycast, BGP routing quirks, and ISP peering disputes complicate simple “nearest is fastest” assumptions.

Privacy, Censorship, and Captive Portals

  • Encrypted DNS (DoH/DoT/dnscrypt) is widely recommended to hide queries from ISPs, though SNI/ECH status is debated.
  • Regulatory context (e.g., GDPR vs. FISA 702) influences trust decisions.
  • Public Wi‑Fi captive portals remain painful when using fixed custom DNS; some rely on OS captive-portal mechanisms or direct IP access as workarounds.