DoH vs DoT: Two Ways to Encrypt Your DNS Queries

Every page you load starts with a question your device asks out loud. Before the first byte of content arrives, something on your machine looks up the domain name, and for most of the internet's life that exchange travelled in plain text on port 53, readable and rewritable by anyone on the path.

Two standards fixed that differently. DNS over TLS puts the same DNS messages inside a TLS connection on a port reserved for the purpose. DNS over HTTPS carries them inside ordinary HTTPS requests. The encryption underneath is identical. What differs is how obvious the whole thing looks to the network you are sitting on.

What plain DNS gives away#

Classic DNS has no encryption and no authentication of the channel. A query for example.com leaves your device as a readable packet containing the full name you asked for, and the answer comes back the same way. Every device between you and your resolver sees the list: the coffee shop router, the ISP, whatever sits in the middle of a corporate network. That list names every site, app backend, and update server your device talks to, in order, with timestamps, and it exists even when the connections that follow are all HTTPS, because the lookup happens first.

Tampering is the other half. Because nothing binds the answer to the sender, a middlebox can substitute a different IP and send you somewhere else. DNSSEC addresses that by signing records so a validating resolver can detect forgery, but it is a signature scheme rather than an encryption one, and a signed record is still readable in transit (DNSSEC explained walks through the chain of trust). Confidentiality needed a separate answer, which is where these two protocols come in.

DNS over TLS: a port of its own#

DoT is specified in RFC 7858. A client opens a TCP connection to port 853, negotiates TLS, then sends unmodified DNS messages inside the encrypted session. The port carries the IANA service name domain-s, and the RFC is strict about what it is for: clients and servers must not use port 853 to transport cleartext DNS. If something is talking on 853, it is talking encrypted.

Because setting up TLS costs a round trip, the specification pushes hard on reuse: clients and servers should keep the connection open rather than close it after each response, following RFC 7766 for the details of persistent DNS-over-TCP connections. One handshake is amortised across a long run of lookups, so the per-query cost after the first is small.

Encryption alone does not tell you who you are encrypting to, so DoT also defines how much you insist on knowing. RFC 7858 offers an opportunistic profile and an out-of-band key-pinned profile built on SPKI fingerprints. RFC 8310 later formalised the pair most people mean today: Strict Privacy, which requires both encryption and authentication and fails hard without them, and Opportunistic Privacy, which tries and may fall back through an unauthenticated connection to cleartext. RFC 8310 draws the line explicitly: a client must not fall back from Strict to Opportunistic mid-query, because that hands an active attacker the downgrade it wants.

DNS over HTTPS: DNS in web clothing#

DoH arrived two years later in RFC 8484 and took a different route: rather than define a new port, it defines a way to move DNS messages over HTTP. The endpoint must use the https scheme and is configured out of band as a URI template, so in practice a DoH query is an HTTPS request to a resolver's URL on port 443, sharing a port with the rest of the web.

The wire format stays familiar. The media type is application/dns-message, and the payload is the same binary DNS message DoT would have sent. Servers must implement both POST and GET: with POST the message goes in the body, and with GET it is base64url-encoded, padding characters omitted, and passed as a variable named dns. HTTP/2 is the minimum recommended version, largely because a stream of DNS lookups over HTTP/1.1 serialises badly.

Riding on HTTP brings HTTP's caching machinery along, so RFC 8484 has to reconcile two notions of freshness. Its rule is that the assigned HTTP freshness lifetime must be no greater than the smallest TTL in the answer section, and that a client reading a cached response subtracts the Age header to see how much of that TTL is left. Without that, an HTTP cache could serve a DNS answer past its expiry.

One footnote: the JSON flavour several large resolvers offer is a vendor convenience, not part of RFC 8484. It is what our own lookups use behind the scenes, but a client that speaks only JSON does not speak the standard.

The difference is visibility, not strength#

People often ask which is more secure. For the payload itself they are the same: both put DNS messages inside TLS, so the strength you get is the strength of the TLS session your client and resolver negotiate. TLS 1.2 vs TLS 1.3 covers what changes between versions, and applies here unchanged.

What differs is how legible the traffic is from outside. DoT announces itself: an operator can see connections to port 853 and count them, permit them, or drop them with one firewall rule, and blocking that port stops DoT entirely. DoH does not stand out. Its packets go to the same port as every image, script, and API call on the network, so telling DNS apart from browsing requires either deeper inspection or a list of known resolver endpoints to block by address. Nothing in the protocol makes DoH harder to decrypt than DoT. It is simply harder to notice.

Whether that is a feature depends on where you stand. On a censoring network, blending into HTTPS is the entire point. For an administrator running split-horizon DNS or filtering malware domains, a silent bypass of the network resolver is a problem, and a visible protocol that can be verified and allowed on purpose is easier to live with.

What neither one hides#

Encrypted DNS moves trust rather than removing it. Your resolver still receives every query in full, because it has to read the name to answer it, and switching from your ISP to a public resolver hands that same complete record to a different operator. It is a choice about whom you trust, not an escape from trusting anyone.

The connection that follows is also still visible. Your network sees the destination IP of every connection you open, so an observer who cannot read your DNS can often infer the answer from where your packets go next. Shared hosting and large CDNs blur that inference; a dedicated IP does not.

Neither protocol hides message lengths on its own, either, and DNS messages vary in size with the name being resolved, so a long enough run of them acts like a fingerprint. RFC 8467 closes that gap with EDNS(0) padding: clients pad queries to a multiple of 128 octets and servers pad responses to a multiple of 468, a size chosen so three blocks still fit inside a typical MTU. That collapses a wide spread of sizes into a few buckets rather than concealing them outright.

Encrypted DNS is a real improvement to a specific weak point, not a substitute for a VPN, for Tor, or for the rest of your privacy posture.

How your device ends up using one#

Configuration is where the two diverge again. DoT is normally a system-wide setting applied by the operating system or the router, so every application inherits it. DoH is frequently set inside a browser, covering that browser's traffic and nothing else, so a laptop can send browser lookups over DoH while every other program on it still resolves in the clear.

There is also a standardised way for a client to find out what its existing resolver supports. RFC 9462 defines Discovery of Designated Resolvers: the client issues an SVCB query for the special-use name _dns.resolver.arpa and learns whether the resolver it already knows by IP also offers DoH, DoT, or DNS over QUIC. It lets a device holding nothing but a plain resolver address upgrade to an encrypted transport with the same operator, rather than switching operators to get encryption.

DNS over QUIC, the third option#

A third transport now sits alongside the other two. RFC 9250 specifies DNS over QUIC on UDP port 853 with the ALPN token doq. The number matches DoT's, but the transport does not: DoT is TCP 853, DoQ is UDP 853, separate protocols sharing a number.

The appeal is latency: QUIC removes the head-of-line blocking TCP imposes, so one lost response no longer holds up the answers behind it. Support is thinner than for the other two, so treat it as promising rather than a default.

Which one should you use#

For a personal device on networks you do not control, DoH is the pragmatic choice: widely implemented, working where unusual ports are blocked, needing no cooperation from the local network.

For a device or network you administer, DoT is often the better fit. Setting it at the router or the operating system covers everything on the device rather than one application, and the dedicated port makes it easy to confirm encrypted DNS is in use.

For a network with a filtering obligation, run encrypted DNS deliberately rather than fight it: a local resolver that speaks DoT or DoH to clients, applies the policy, and forwards upstream over an encrypted transport gets the confidentiality without the blind spot. And whichever you pick, choose the resolver operator on purpose. The protocol decides who cannot see your queries; the operator decides who can.

Checking what you actually have#

Configuration and reality part company more often than you would expect, because one layer overrides another: a VPN client pushes its own resolver, a router intercepts port 53 and answers locally, a browser's encrypted DNS setting turns itself off on a managed network.

Our DNS leak test compares the resolver that answers a probe against the network your connection is coming from, flagging the mismatch that usually means queries are escaping a tunnel you thought they were inside. Its scope is worth stating plainly: it observes the resolver on the path, not the setting on your device, so it reports what happened rather than what you asked for. DNS leak testing covers how to read the result.

For the records themselves, our DNS lookup resolves A, AAAA, MX, TXT, NS, CNAME, and SOA over Cloudflare's DoH endpoint, and what is a DNS record explains what each type carries. The propagation checker queries a set of public resolvers over their own DoH endpoints at once, which shows how differently two resolvers can answer the same question.