Encrypted DNS Compared: DoH vs DoT vs DNSCrypt vs Oblivious DoH

DNS was designed in 1983 as a cleartext UDP protocol on port 53. Every query — example.com, signal.org, that-embarrassing-search.example — is broadcast unencrypted to your configured resolver, and any router between you and that resolver can read it. That made sense in a research network. It does not make sense on a modern hostile internet, where ISPs sell browsing data, public Wi-Fi is run by strangers, and authoritarian networks block traffic by sniffing DNS.

Four protocols address this, each by encrypting DNS queries differently. DoH wraps queries in HTTPS. DoT wraps them in dedicated TLS on its own port. DNSCrypt was the first widely-deployed encrypted DNS, predating both. Oblivious DoH (ODoH) layers an additional relay between you and the resolver. They sound similar. The differences matter.

What encrypted DNS actually protects

Before comparing protocols, the threat model has to be clear. Encrypting DNS hides query contents from:

• Your local network — the coffee shop router, your ISP's middleboxes, anyone sniffing the Wi-Fi.
• On-path observers between you and the resolver — transit ISPs, network surveillance.

Encrypting DNS does not hide:

• The destination IP address. Once DNS resolves example.com to 93.184.216.34, your packets still go to that IP in cleartext at the IP layer. Your ISP sees the connection.
• The TLS Server Name Indication (SNI). When you connect to an HTTPS site, the hostname is sent in the clear during the TLS handshake unless Encrypted Client Hello (ECH) is in use.
• The resolver itself. Whatever provider you point your encrypted DNS at gets a complete log of every query you make. You've moved the trust, not eliminated it.

DoT — DNS over TLS (RFC 7858, 2016)

DoT is the most architecturally simple of the four. It runs DNS over a dedicated TLS connection on TCP port 853. The wire format is unchanged — it's still the same DNS message wire format defined in RFC 1035 — just wrapped in TLS instead of sent in cleartext UDP.

Because DoT uses a dedicated port, network operators can identify and block it trivially with a single firewall rule. Some jurisdictions and many corporate networks do exactly this. For users in those environments, DoT is not an option.

Operationally, DoT is the cleanest protocol for system-wide use. Android's "Private DNS" setting and most Linux systemd-resolved configurations use DoT because it doesn't require an HTTP stack — it's a simple TLS connection a stub resolver can manage natively.

DoH — DNS over HTTPS (RFC 8484, 2018)

DoH wraps DNS messages in HTTPS requests to /dns-query endpoints on standard port 443. To a network observer, DoH traffic looks identical to ordinary web traffic. This is its central design property — and the most controversial one.

Censorship resistance: Blocking DoH means blocking HTTPS, which is impractical for most network operators. This is good for users in restrictive networks and bad for legitimate use cases like enterprise DNS-based malware filtering, school content controls, and parental supervision tools that depend on visible DNS queries.

Application-level resolution: Because DoH is HTTPS, individual applications can implement their own DoH client and bypass the operating system's DNS configuration entirely. Firefox does this by default in many regions, sending queries to Cloudflare even if the system is configured to use a different resolver. This breaks the assumption that all applications on a device share a DNS context.

DNSCrypt (2011, no RFC)

DNSCrypt predates both DoT and DoH by several years. It was developed by OpenDNS (now part of Cisco) in 2011 and uses authenticated encryption with X25519 key exchange and XChaCha20-Poly1305 or XSalsa20-Poly1305 ciphers. The protocol works over both UDP and TCP, typically on non-standard ports.

Because DNSCrypt was never standardized by the IETF, it has not seen the same adoption as DoH and DoT in operating systems and major browsers. Its main user base is privacy-focused communities running dnscrypt-proxy as a local stub resolver. The DNSCrypt project also maintains an "anonymized DNSCrypt" mode that routes queries through a relay (similar in spirit to ODoH, below) and predates ODoH by several years.

DNSCrypt's main practical advantage today is the active ecosystem of resolvers maintained by independent operators — many smaller, less-surveillance-prone providers offer DNSCrypt but not necessarily DoH or DoT.

Oblivious DoH — ODoH (RFC 9230, 2022)

ODoH is structurally different from the other three. Standard DoH still lets the resolver correlate your IP address with your queries. ODoH attempts to break that correlation by introducing a relay between the client and the resolver:

1. The client encrypts the DNS query with the target resolver's public key.
2. The client sends the encrypted query to a relay, which sees the client's IP but cannot decrypt the query.
3. The relay forwards the encrypted query to the resolver, which decrypts it but sees only the relay's IP — not the client's.
4. The response travels back through the relay encrypted to the client.

As long as the relay and the resolver do not collude, neither party alone has the combination of who you are and what you asked. This is a meaningful improvement over standard DoH, where the resolver has both.

ODoH's weaknesses are practical: it depends on at least two trusted parties, deployment is sparse (Cloudflare runs the main public infrastructure), and the relay/resolver pair must be operated by independent organizations to make the non-collusion assumption meaningful.

Side-by-side comparison

Property	DoT	DoH	DNSCrypt	ODoH
Default port	853 (dedicated)	443 (HTTPS)	Varies	443 (HTTPS)
Censorship-resistant	No (easy to block)	Yes (looks like HTTPS)	Partial	Yes
Hides query from resolver IP correlation	No	No	Optional (anonymized mode)	Yes (with relay)
Application bypass risk	Low	High (per-app resolvers)	Low	High
OS-level support	Broad	Growing	Add-on only	Limited
IETF standardized	RFC 7858	RFC 8484	No	RFC 9230

What to pick

For most users on most devices, DoH or DoT to a resolver you trust is the right baseline. Apple, Google, and Mozilla all default to encrypted DNS now; the marginal benefit over the system default is mostly about resolver choice, not protocol choice.

For users in censorship-heavy networks, DoH or ODoH are the only protocols that survive aggressive blocking. DoT will be filtered at the firewall.

For users who want to separate who they are from what they ask, ODoH is currently the only option that does this without going through Tor. If your threat model justifies the operational complexity, it's worth setting up.

For users running their own infrastructure, DNSCrypt remains a strong choice because the resolver ecosystem includes many small, independent operators who do not also run cloud businesses.

What encrypted DNS doesn't fix

Encrypted DNS is a real improvement, but it solves a narrow problem. The destination IP address still leaks to anyone watching your connection, and the TLS handshake still includes the server's hostname in cleartext unless ECH is enabled. A comprehensive privacy posture for DNS-equivalent metadata requires combining encrypted DNS with Encrypted Client Hello, and often with a VPN or Tor for IP-level protection.

If your goal is to keep specific browsing private from your ISP, encrypted DNS alone is not enough — you also need to hide the IP packets. If your goal is to keep query patterns private from the resolver, ODoH or DNSCrypt's anonymized mode is the right tool. If your goal is to bypass censorship, DoH is the most survivable choice. Picking based on the actual threat model is the work.