Explainer · privacy

DoH vs DoT — DNS encryption, two flavors

Both stop your ISP from reading your DNS queries. They differ in how visible they are on the wire, who they protect from whom, and what your network operator can do about them.

Why DNS encryption exists

Classic DNS, defined in RFC 1035 (1987), is plaintext UDP over port 53. Anyone on the network between your client and the resolver — your ISP, the coffee-shop router, the airport Wi-Fi, the state-level firewall — can read every query and every answer. They learn which websites you visit, which apps you use, and which services you depend on, all without seeing a byte of the actual application traffic.

That visibility has been quietly exploited for decades. ISPs sell DNS-query data to marketing aggregators. Some governments use unencrypted DNS to enforce censorship by returning false answers. Coffee-shop attackers can intercept and rewrite responses. Encrypted DNS — DoH or DoT — closes that hole.

DNS over HTTPS (DoH, RFC 8484)

DoH wraps DNS queries inside HTTPS requests. Each query is an HTTP POST (or GET with the query in a base64url parameter) to the resolver's /dns-queryendpoint on port 443. The response is an HTTP body containing the standard DNS wire format. The TLS layer encrypts everything.

What it looks like on the wire: indistinguishable from any other HTTPS connection to that resolver's domain. A network observer sees you talking to mozilla.cloudflare-dns.com or dns.google over TLS 1.3 on port 443 — exactly like millions of other web sessions.

Where it lives: built into Firefox (enabled by default in the US since 2020 and progressively in other regions), Chrome, Edge, and Brave. Available on every modern OS with various levels of system integration.

The 'looks like web traffic' property is the feature. A network that wants to block DoH cannot block port 443 — that breaks all of HTTPS. They have to block specific DoH provider IPs or domains, which is a moving target as new providers come online and old ones change addresses.

DNS over TLS (DoT, RFC 7858)

DoT puts DNS in a TLS stream on a dedicated port: 853. The protocol inside the TLS tunnel is the standard DNS wire format — same as classic UDP/53, just wrapped in TLS.

What it looks like on the wire: TLS to a known DoT provider IP on port 853. Identifiable as DNS traffic specifically, not "any HTTPS connection." Network operators can apply DNS-specific policies (allow, block, log) at the port level.

Where it lives: Android (default since version 9 / Pie), systemd-resolved on Linux, all major commercial routers, BIND, Unbound, dnsmasq. Less commonly used in browsers directly because Android handles it at the OS level.

The "explicit identification" property is also the feature — but from a different angle. Enterprises that want to enforce DNS policy can permit DoT to a corporate resolver and block other DoT IPs at the firewall. With DoH that policy is much harder to enforce because the traffic looks like normal HTTPS.

The choice in one paragraph

For end users: pick DoH if you want resilience against blocking and indistinguishable traffic; pick DoT if your operating system supports it natively and you don't have a specific reason to prefer DoH. Either is dramatically better than plaintext DNS. For network operators: DoT lets you enforce policy at the port level; DoH lets you push the policy decision to the application layer. Both have legitimate deployments.

The trade-offs in detail

Privacy from the local network

DoH and DoT both completely hide the DNS query content from anyone between your client and the resolver. Identical privacy guarantees against this threat.

Privacy from the network operator's policy

DoH is harder to block. DoT is easier to allow selectively. In a coffee shop or a censorious country, DoH bypasses more interference. In a corporate network with legitimate DNS-policy needs, DoT is friendlier.

Privacy from the resolver itself

Neither protocol changes this. The resolver you pick (Cloudflare, Google, Quad9, NextDNS, your own) sees every query you make. You are trusting them with whatever your ISP used to see. Resolver choice matters more than DoH vs DoT — they're equivalent against on-path observers but their privacy posture against the resolver itself depends on the provider's logging and data-sharing policies.

Performance

DoH adds modest overhead — TLS handshake (often amortized via 0-RTT resumption on repeat connections), HTTP headers per request. Modern implementations are within a few milliseconds of plaintext UDP for individual queries. DoT is slightly faster than DoH because it skips the HTTP layer. Both are dominated by the round-trip time to the resolver, which makes geography matter more than protocol choice. Cloudflare's anycast network typically puts the resolver within ~10 ms of you anywhere on Earth.

Censorship resistance

DoH wins. A state-level firewall that wants to block "DoH" has to block specific provider IPs and domains, and new providers can come online faster than blocklists update. DoT to port 853 is trivially blocked by a single firewall rule. Real-world deployments in censored regions favor DoH for this reason.

Enterprise visibility

DoT wins from the operator perspective. A company with a security policy that requires DNS visibility can run their own DoT resolver, mandate it via system configuration, and block port 853 to other destinations at the firewall. DoH undermines this entirely — if a user can reach any HTTPS site, they can probably run DoH to a public resolver.

Operating-system integration

DoT has better OS support today — Android handles it transparently since 2018, systemd-resolved supports it, Windows DNS Client supports it (Windows 11). DoH is better in browsers and is gradually being added to OS-level resolvers (macOS Big Sur added DoH/DoT profiles in 2020; Windows 11 added DoH in 2021).

How to configure each

Browser-level DoH

OS-level DoT or DoH

Which resolver to pick

Common pitfalls

Related reading