DNS is the last unencrypted hop most users don’t think about. Type a domain, and unless you’ve changed defaults, your operating system fires a UDP packet to whatever resolver your ISP, hotel Wi-Fi, or mobile carrier handed you — in plaintext, on port 53, visible to anyone on the path. Mozilla now reports DoH adoption above 85% among U.S. Firefox users, Apple’s iCloud Private Relay routes DNS through Oblivious DoH on Cloudflare infrastructure, and dnscrypt-proxy saw its latest tag on April 23, 2026. The plaintext default is dying. What replaces it is not one protocol but four, with different threat models and very different deployment footprints.
This piece walks the four protocols you’ll actually encounter — DoH (DNS over HTTPS), DoT (DNS over TLS), DNSCrypt, and ODoH (Oblivious DNS over HTTPS) — what each one hides, what it doesn’t, and where each fits. The framing matters because “encrypted DNS” is marketing, not a single property. A DoH query to Cloudflare encrypts your traffic and hands Cloudflare your IP plus your full query history. ODoH fixes the second half; DoT fixes neither. Choose the wrong one for your threat model and you’ve moved the surveillance target, not removed it.
What Each Protocol Actually Encrypts — And What It Doesn’t
The four protocols share one goal — keep DNS contents off the wire in plaintext — and diverge on everything else: transport, port, certificate model, and whether the resolver gets to see who you are.
DoT is the simplest. RFC 7858 wraps standard DNS messages in a TLS tunnel on TCP port 853. The resolver sees your IP and your queries; the network in between sees encrypted bytes on a port that screams “DNS.” That visibility is a feature for enterprise networks that want to allow encrypted DNS while still blocking it at the firewall, and a bug for users on networks that drop port 853 entirely.
DoH (RFC 8484) sends DNS messages as HTTPS requests on port 443, which makes them indistinguishable from any other web traffic at the TCP layer. This is what makes DoH controversial: a network operator can’t trivially block it without breaking general HTTPS, which is why corporate, school, and parental-control software treats browser-level DoH as a threat to enforcement. Firefox runs canary-domain checks before enabling DoH so that filtered networks can opt out, and Chrome only auto-upgrades to DoH when the system resolver is already a known DoH provider — different reactions to the same tension.
DNSCrypt predates the IETF protocols and takes a different shape. The draft-denis-dprive-dnscrypt-08 document published March 29, 2026 brings the protocol — first deployed in 2013 — into the formal IETF process for the first time. DNSCrypt clients are pre-configured with a resolver’s IP address and long-term provider public key, so they never resolve a hostname through plaintext DNS to find their resolver. There is no certificate authority in the trust path. The trade-off is reach: you get strong authentication and clean bootstrap, but you depend on a community-maintained server list rather than browser-vendor partnerships.
ODoH (RFC 9230, experimental, published 2022) is the only one of the four that addresses the resolver-as-observer problem. It inserts a proxy between client and target. The client encrypts its query end-to-end to the target using HPKE — Hybrid Public Key Encryption — so the proxy sees an encrypted blob and the client’s IP, while the target sees the proxy’s IP and the decrypted query. Unless the proxy and target collude, no single party links query content to client identity. Cloudflare runs an ODoH target at odoh.cloudflare-dns.com; PCCW, SURF, and Equinix run launch proxies. iCloud Private Relay was built on the same separation principle.
How DoH and DoT Sit on the Wire
DoT’s wire shape is the easy one. The client opens a TCP connection to the resolver on port 853, completes a TLS 1.2 or 1.3 handshake, and sends standard DNS wire-format messages prefixed with a two-byte length field — exactly as DNS-over-TCP has always worked, just inside a TLS tunnel. Connection reuse keeps performance close to UDP after the first handshake. Because port 853 is a registered, named DNS port, network operators can identify and selectively allow or deny it. That’s the design. DoT was written for explicit, configured trust between a stub resolver and an upstream — typical use is a phone or laptop pointing at an ISP’s or organization’s resolver, not a browser making decisions on its own.
DoH inherits HTTP semantics, which adds capability but also overhead. A query is either an HTTP GET with a base64url-encoded message in a dns parameter, or an HTTP POST with the message in the body, both with Content-Type: application/dns-message. The response carries the same content type. Because the request is HTTP, intermediate caches and load balancers can act on it the way they would any HTTPS request, and it benefits from HTTP/2 multiplexing and HTTP/3’s QUIC transport when the server supports them. The downside is the visibility surface: the resolver operator now runs a web service that necessarily sees source IPs, request timing, and whatever fingerprint the HTTP client emits.
Both protocols rely on the public CA system to authenticate the resolver. That’s a real difference from DNSCrypt, which is engineered to avoid CAs entirely and is sometimes preferred on networks where the operator distrusts the WebPKI.
Why ODoH Exists — The Resolver Is Now the Threat
The original DoH and DoT threat model treats the local network as adversarial and the resolver as trusted. That assumption breaks once a handful of operators handle most encrypted DNS queries on the internet. The 2021 PoPETs paper by Singanamalla and co-authors made this argument concretely: large-scale DoT and DoH deployments concentrate query metadata at a small number of operators, who can link queries to client IPs and therefore to identities. Encryption against the network doesn’t help if the encrypted endpoint is the new observer.
ODoH splits the trust. The client picks a proxy and a target independently and encrypts its query payload to the target using HPKE — specifically, the DHKEM(X25519, HKDF-SHA256) / HKDF-SHA256 / AES-128-GCM ciphersuite in the original deployment. The proxy receives an opaque ciphertext and forwards it to the target; the target decrypts, resolves, encrypts the response using a key derived via derive_secrets from the query plaintext and a response nonce, and returns it through the proxy. Two encryption layers run simultaneously: TLS on each hop, plus end-to-end HPKE between client and target. The proxy can’t read the query. The target can’t see the client IP. Singanamalla et al. measured median query latency of 334.85 ms on the lowest-latency proxy-target pair, with page-load time impact of roughly 1.3 → 1.6 seconds — visible but not crippling.
The catch is that the privacy guarantee depends on the proxy and target not colluding. ODoH is a non-collusion model, not a cryptographic guarantee against a hostile operator. In practice, that means picking a proxy run by an organization with no commercial relationship to your target, and ideally in a different legal jurisdiction.
DNSCrypt’s Different Bet
DNSCrypt looks dated next to ODoH on paper — it’s older, it’s not an RFC yet (the IETF draft is informational and was just published in March 2026), and it doesn’t split trust by default. Its appeal is operational. The protocol is documented at dnscrypt.info/protocol/ and implemented across dnscrypt-proxy, encrypted-dns-server, and clients like SimpleDnsCrypt, all maintained under the DNSCrypt GitHub organization with active commits through April 2026.
Three properties keep DNSCrypt relevant. First, no CA dependency: clients are configured with a resolver’s IP and a long-term provider public key, and the protocol uses cryptographic signatures over short-term resolver certificates that the client refreshes hourly. Second, no plaintext bootstrap: DoH and DoT both have to resolve their resolver’s hostname somehow, usually via system DNS, which leaks before the encrypted channel ever opens. DNSCrypt has no such window. Third, the protocol has no SNI, no fixed HTTP signature, and runs over UDP or TCP on port 443, so traffic-analysis blocking is harder than for DoT and somewhat harder than for DoH because there’s no TLS ClientHello with a cleartext server name.
The Anonymized DNSCrypt extension, announced October 2019, adds a relay between client and resolver — analogous to ODoH’s proxy — to hide the client IP from the resolver. The DNSCrypt resolver list at github.com/DNSCrypt/dnscrypt-resolvers includes operators like Snowstorm running ODoH targets alongside the older DNSCrypt servers, so deployments often mix protocols against the same proxy infrastructure.
What Encrypted DNS Doesn’t Hide
Encrypted DNS is not a privacy panacea, and the most common misunderstanding is treating it as one. Three leaks remain on a typical connection.
SNI in TLS handshakes. TLS 1.2 and 1.3 (without ECH) send the destination hostname in cleartext as the Server Name Indication. Encrypting your DNS query for example.com and then immediately opening a TLS connection that announces example.com in plaintext defeats half the privacy gain. Encrypted Client Hello (ECH), enabled in Firefox 118 and later when DoH is also active, plugs this. Without ECH, encrypted DNS still helps against on-path observers who lack visibility into TLS metadata, but a passive ISP-grade observer can usually reconstruct most of your browsing from SNI alone.
Connection-IP correlation. Once DNS resolves, you connect to a destination IP. For dedicated, single-tenant IPs, that’s effectively a domain disclosure. ODoH doesn’t help with this — it protects DNS only.
OS-level resolver bypass. A lot of “encrypted DNS” deployments are browser-only. The OS resolver still sees mDNS, captive portal probes, software updates, and any application that doesn’t honor browser DoH settings. macOS and Windows 11 both support system-level DoH/DoT, but defaults and enforcement are uneven across versions.
Deployment in 2026 — What’s Actually Running
Browser support is broad and uneven. Firefox enables DoH by default in the U.S., Canada, Russia, and Ukraine, with rollout to additional regions ongoing; the default U.S. resolver is Cloudflare, with NextDNS and others available via the Trusted Recursive Resolver program. Chrome’s “Use Secure DNS” feature is on by default but conservative — it auto-upgrades to DoH only when the system resolver is a known DoH provider, which means Chrome generally enhances rather than diverts your existing DNS. Edge follows Chrome’s behavior. The asymmetry creates a real enterprise-management problem: Mozilla reports DoH adoption above 85% among U.S. Firefox users, which is the population network filtering products are designed to manage.
Operating systems lag browsers. Windows 11 supports DoH on built-in resolvers. iOS and macOS expose DoH and DoT via configuration profiles, and iCloud Private Relay layers ODoH on top for Safari traffic when enabled. Android has supported “Private DNS” — DoT — since Android 9.
Public resolver support: Cloudflare’s 1.1.1.1 runs DoH, DoT, and ODoH (target endpoint odoh.cloudflare-dns.com); Google Public DNS runs DoH and DoT; Quad9 runs DoH, DoT, and DNSCrypt. The DNSCrypt community list at github.com/DNSCrypt/dnscrypt-resolvers aggregates dozens of smaller operators with varying logging policies — useful when you specifically want to avoid the big three.
DNS-over-QUIC (DoQ, RFC 9250) sits adjacent to this conversation. It’s effectively DoT moved onto QUIC instead of TCP+TLS — same trust model, lower handshake latency, fewer head-of-line blocking issues. AdGuard and a handful of other resolvers support it; mainstream browser adoption hasn’t followed.
Frequently Asked Questions
Does encrypted DNS replace a VPN? No. A VPN tunnels all traffic to an exit point and changes your apparent IP for everything; encrypted DNS only protects DNS lookups. The DNSCrypt project explicitly warns of this confusion. Encrypted DNS plus a VPN is meaningful — your DNS queries are protected even if your VPN provider doesn’t run their own resolver.
Can my employer still filter DNS if I’m using browser DoH? Often yes. Firefox honors enterprise policies and a network canary domain, so a properly configured corporate network signals “do not use DoH” and Firefox respects it. Chrome’s auto-upgrade only triggers when the system resolver is a participating DoH provider, so corporate DNS that points at an internal resolver simply won’t be upgraded. Adversarial bypass — a user manually choosing a third-party DoH provider — requires GPO or registry policy enforcement to block.
Should I use ODoH for everything? Probably not yet. RFC 9230 is experimental, target deployments are limited (Cloudflare is the practical option for general use), and you take a latency hit on the order of 50–100 ms per query. Use it where the resolver-as-observer threat is real to you — research, journalism, sensitive lookups — and standard DoH or DoT for everyday browsing.
What about DNSSEC? DNSSEC authenticates DNS responses against tampering but doesn’t encrypt them; it’s orthogonal to the four protocols here. ICANN is preparing a 2026 root zone signing key rollover with a new trust anchor. Mozilla has stated they prioritized DoH over DNSSEC for user privacy and are still considering DNSSEC implementation in Firefox.
The Honest Recommendation
For most people, system-level DoH or DoT pointed at a resolver whose privacy policy you’ve actually read is the right answer. It’s the floor, not the ceiling — but it removes the easiest surveillance vector (your ISP) and the easiest tampering vector (anyone on coffee-shop Wi-Fi) without changing how anything works. For users with a meaningful threat model around resolver-side correlation, ODoH via 1.1.1.1 with a non-Cloudflare proxy, or DNSCrypt with the Anonymized extension, is worth the configuration effort. Don’t run all four. Don’t assume any of them protect you against destination-IP correlation or unencrypted SNI — pair with ECH where available.
The protocol war is over: DNS in plaintext is the legacy default, and within a few years it will be the explicit exception. The interesting question now is which trust model you accept. Pick deliberately.
