Your DNS resolver sees everything. Here's how to pick one that doesn't sell it.

What happened

A 6,000-word guide titled *Choosing a Public DNS Resolver* hit 222 points on Hacker News this week, and the comment section did what HN comment sections do best when the topic is infrastructure most developers haven't thought about since they configured their first home router: it argued for 800 comments and surfaced about a dozen genuinely useful operational details.

The guide, hosted at evilbit.de, walks through the major public resolvers — Cloudflare's 1.1.1.1, Google's 8.8.8.8, Quad9's 9.9.9.9, OpenDNS, AdGuard DNS, Mullvad DNS, NextDNS, and ControlD — and grades them on logging policy, jurisdiction, transport security (DoH/DoT/DoQ), filtering behavior, anycast performance, and DNSSEC validation. The author's core thesis is that resolver choice is a privacy decision dressed up as a performance one, and most developers get the math backwards.

The numbers in the guide are worth restating. Cloudflare's 1.1.1.1 claims 24-hour log retention with KPMG audits. Google's 8.8.8.8 retains "temporary" logs for 24-48 hours and "permanent" anonymized logs indefinitely. Quad9 is Swiss-incorporated and claims no IP logging at all. NextDNS lets you configure retention down to zero. The performance gap between the top four, measured from a typical residential connection, is roughly 3-8ms — well below the threshold of human perception and below the noise floor of most home networks.

Why it matters

DNS is the last great unencrypted protocol most developers still use without thinking. Every API call your laptop makes, every npm install, every `git clone`, every container pull starts with a DNS query that — unless you've explicitly configured otherwise — leaves your machine in plaintext UDP on port 53. Your ISP sees it. Anyone on the coffee shop wifi sees it. The resolver sees it by definition. And the resolver is almost always the default one your DHCP lease handed you, which means it's almost always your ISP's.

The HN thread surfaced the uncomfortable counterpoint that DNS-over-HTTPS and DNS-over-TLS — the standard advice for the last five years — only encrypts the hop between you and the resolver. Your ISP still sees the destination IP of every connection you make, and with TLS 1.2 they still see the SNI in cleartext. Encrypted Client Hello (ECH) is rolling out but adoption is uneven; Cloudflare turned it on for their reverse proxy customers in 2023, but the origin server has to support it too, and most don't. So the actual privacy delta from switching resolvers is smaller than the marketing implies — you're trading one observer (your ISP) for another (the resolver operator), and hoping the second one has a better privacy policy than the first.

This is where jurisdiction matters more than transport. A US-based resolver operating under a National Security Letter cannot tell you it received one; a Swiss resolver operating under Swiss law can. Quad9 moved its headquarters from California to Zurich in 2021 specifically to escape the FISA regime. Mullvad operates out of Sweden and accepts cash payments by mail. These aren't paranoid edge cases — they're the reason the EFF's recommendation list looks different from the Cloudflare marketing page.

The guide also makes a point that gets buried in most resolver comparisons: filtering is not the same as blocking, and blocking is not the same as malware protection. Quad9 blocks ~190,000 known-malicious domains using threat intel from 19 partners; AdGuard DNS blocks ~1M+ ad and tracker domains; NextDNS lets you compose your own blocklists. These are different products solving different problems, and choosing the wrong one means either your CI pipeline mysteriously can't resolve a CDN, or your work laptop is leaking telemetry you thought you'd blocked.

What this means for your stack

If you're shipping code from a laptop, the practical configuration is: DoT or DoH to a non-default resolver at the OS level, with a local stub resolver doing DNSSEC validation. On macOS, that's a configuration profile pointing at `https://dns.quad9.net/dns-query` or `https://mozilla.cloudflare-dns.com/dns-query`. On Linux, systemd-resolved supports DoT natively since version 239 — set `DNS=9.9.9.9#dns.quad9.net` and `DNSOverTLS=yes` in `/etc/systemd/resolved.conf` and you're done. On Windows 11, it's in the network adapter properties under DNS encryption.

If you're running infrastructure, the calculus is different. Your production resolvers should be Unbound or PowerDNS Recursor running inside your VPC, not a public resolver. Public resolvers introduce a third-party dependency on a request that fires before every outbound connection your service makes — including the ones to AWS, GCP, and your own database. When 1.1.1.1 had its 2020 outage, half the internet's serverless functions started timing out on DNS lookups they didn't realize they were doing. Run your own recursive resolver. Cache aggressively. Set sane TTLs.

For the home network, the under-appreciated move is splitting horizons. Router-level DoT to one resolver for the IoT VLAN (where you want filtering — block the smart TV's telemetry domains), DoH at the OS level on the work laptop to a different resolver (where you want zero logging), and a Pi-hole or AdGuard Home in the middle doing local resolution for `.lan` and caching everything else. The configuration takes an hour. The privacy delta from the default ISP resolver is enormous.

Looking ahead

The quiet shift coming in 2026 is Oblivious DNS over HTTPS (ODoH), which separates the entity that sees your IP address from the entity that sees your query. Cloudflare and Apple have been running an ODoH pilot since 2021; iCloud Private Relay uses a similar architecture. Once ODoH ships at scale, the resolver-choice question stops being about trusting one company and starts being about trusting that two companies aren't colluding — a meaningfully different threat model. Until then, the answer is the boring one: read the privacy policy, pick a jurisdiction you trust, encrypt the transport, and assume the resolver is logging anyway.