"Encrypt your DNS and your ISP can't see where you go" is one of the most repeated pieces of privacy advice, and it is mostly wrong. Encrypted DNS - DoH or DoT - is worth running, but not for the reason it is usually sold. It hides one of the three ways your ISP learns which sites you visit, and leaves the other two wide open. If you run Pi-hole with Unbound, as a lot of self-hosters do, the picture has an extra twist worth understanding before you believe the resolver gave you privacy it did not.
//Three Ways Your ISP Learns the Site
Visiting a site involves two steps your ISP can watch. First a DNS lookup turns the hostname into an IP address. Then your browser opens a TLS connection to that IP. Across those two steps, the destination is revealed three separate ways: the hostname in the DNS query, the server name in the TLS handshake, and the destination IP address itself. Encrypted DNS addresses exactly one of the three.
The destination IP always leaks
Your ISP has to route your packets, so it always sees the IP address you are talking to. For a site on a dedicated IP, the address alone names it. The only thing that muddies this is a large shared CDN, where thousands of sites sit behind one address - then the IP tells an observer "something on Cloudflare" and little more.
The server name leaks in the TLS handshake
When your browser connects, it sends the server name it wants - the SNI - in the very first message of the TLS handshake, the ClientHello, in cleartext, before any encryption is established. This is true in TLS 1.2 and 1.3 alike; TLS 1.3 encrypted the server's certificate but not the SNI. So even with DNS fully encrypted, the first packet of each HTTPS connection still announces the hostname to anyone on the path.
//So What Does Encrypting DNS Actually Do?
It encrypts the DNS query between you and your resolver, which means that specific channel no longer spells out the hostname to the ISP - if your resolver is not the ISP. That is genuine. But because the SNI and the IP still give the site away, your ISP generally still knows where you went. What encrypting DNS really changes is who aggregates your query history. Send it to a third-party resolver like Cloudflare or Quad9 and you have handed your full browsing stream to a new company instead of your ISP. You did not remove the watcher; you chose a different one.
//The Pi-hole + Unbound Case, Honestly
Running Pi-hole with Unbound as a recursive resolver is a genuinely good setup, and it gives you two real things: you block ad and tracker domains at the network, and no single upstream resolver gets a copy of your entire DNS history - Unbound walks the chain from the root servers itself, so your queries are split across the authoritative servers for each zone rather than aggregated by one provider. That is a meaningful privacy property and the honest reason to run it.
What it does not do is hide your browsing from your ISP. Unbound's queries to the root, TLD and authoritative servers go out over plain port 53, so your ISP can see those lookups on the wire - and the SNI and destination IP leak as always. Encrypting DNS to a local Unbound adds nothing, because that traffic never leaves your network in the first place; DNSSEC validation, which Unbound does, is integrity, not confidentiality. The setup is worth running. Just run it for the ad-blocking and the de-aggregation, not for an invisibility it does not provide.
//Encrypted Client Hello: the Piece That Closes the SNI Gap
The one development that actually hides the server name is Encrypted Client Hello, standardised in 2026 as RFC 9849. ECH wraps the real ClientHello - SNI and all - inside an encrypted extension of an outer ClientHello that carries only a shared placeholder name. Done right, the on-path observer no longer sees which site you asked for.
The caveats matter. ECH needs the client to fetch the site's public key, published in a DNS HTTPS/SVCB record, which should itself be fetched over encrypted DNS or the key name leaks. It needs the hosting provider or CDN to support it - in practice Cloudflare is the main deployment, using a shared outer name. And crucially, ECH does not hide the destination IP - RFC 9849 says so explicitly. So ECH is a real gain on a big shared CDN, where the IP is ambiguous and the SNI was the only thing naming the site; on a dedicated IP, closing the SNI gap still leaves the address pointing straight at the destination. Some networks also strip ECH keys from DNS answers to force a fallback, so coverage is uneven.
//Sourcing and Framing
The cleartext-SNI behaviour in TLS 1.2/1.3 and the ECH design are from Cloudflare's engineering documentation and RFC 9849, "TLS Encrypted Client Hello" (Proposed Standard, March 2026); the point that ECH does not hide the destination IP is stated in the RFC itself. The Pi-hole + Unbound analysis - no single resolver aggregating your history, versus the ISP still seeing destination IP, SNI, and the recursive lookups on the wire - follows the Pi-hole maintainers' own clarification on the subject. The dependency of ECH on an HTTPS/SVCB record fetched over encrypted DNS and on CDN support is from the Cloudflare ECH documentation. The framing - that encrypting DNS mostly relocates who aggregates you rather than hiding where you go - is the consistent thread across this and the VPN piece.