DNS over TLS vs DNS over HTTPS

DNS over TLS and DNS over HTTPS are the two standard ways to stop plaintext DNS queries from being read on the wire. Both encrypt the query between the client and the recursive resolver, and both are the result of DNS famously travelling unencrypted by default, letting an observer on an ordinary network see every hostname a device looks up. The two methods differ mostly in transport: the first runs DNS over a raw TLS connection, and the second runs it inside HTTPS.

How each transports DNS

DNS over TLS, shortened to DoT, is defined in RFC 7858. It establishes a TLS connection directly to a resolver on port 853 using TCP, and sends ordinary DNS messages over that encrypted tunnel. A DoT resolver listens on port 853 by default and expects every query there to be TLS protected. Because it reuses the normal DNS message format, it is comparatively simple for resolvers and works over the long-lived connection the TLS session provides.

DNS over HTTPS, shortened to DoH, wraps DNS queries in HTTPS requests to a web endpoint, normally on port 443, using the same path a browser would use for any other secure web request. The query is carried in the HTTPS request and the answer in the response, so DoH traffic is indistinguishable from regular HTTPS traffic on the network. DoH is specified in RFC 8484, and a browser can hand the resolver the same location it would for a web page.

Where they differ

The visibility difference matters to networks that filter or inspect traffic. A DoT connection to port 853 is distinguishable from other traffic, so a middlebox that blocks 853 blocks DoT outright. A DoH query rides on 443 and looks exactly like an encrypted web request, so it is far harder to block without breaking the web itself. That same property is what some networks dislike, since it can bypass local DNS filtering or content policy.

Latency and connection handling also differ in practice. DoT benefits from keeping a single TLS connection open for many queries, which suits recursive resolvers and systems that copy the resolver behaviour. DoH is more natural for browsers and applications that already speak HTTPS, and it allows the client to use the exact same server and edge for DNS as for content. Neither encrypts the DNS payload selectively; both encrypt the whole query stream end to end between client and resolver.

Which to prefer

For most people the choice is driven by what their software already supports. Browsers route secure DNS through DoH by default in their settings, often using DoH as the secure-DNS mechanism, and geo-network administrators commonly configure resolvers to offer both. Quad9 and Cloudflare, among others, publish DoH and DoT endpoints for the same anycast servers, so you rarely have to choose one over the other as a hard either-or.

Pick DoH when you want privacy that is indistinguishable from ordinary HTTPS traffic, for example on a network that inspects traffic, and when your client is a browser or an app that speaks HTTPS naturally. Pick DoT when you run a resolver, want a simple long-lived encrypted DNS channel, or have software that only speaks the DNS protocol and you want to protect it at the resolver with a stable 853 listener.

Whichever you use, the traffic is only encrypted to the recursive resolver you pick. The query still travels between that resolver and the authoritative servers for the domain, and any filtering happens there. For the query flow itself, see DNS resolution and propagation and the DNS over HTTPS coverage, and if a resolver stops answering, DNS server not responding is the follow-up.