Encrypted DNS: DoT, DoH & DoQ

Look at it from the point of view of a single question. You type www.shop.example into a browser on a café's Wi-Fi. Before anything else happens, your device's stub resolver writes a small DNS query, perhaps 40 bytes, and sends it as one UDP packet to port 53 on the resolver it was given. The query contains the name, the record type and nothing else that is secret, but that is already a lot: the name of every site you visit, every app that phones home, every mail server your laptop checks, in order and with timestamps.

The DNS data itself is public. Anyone can look up www.shop.example, and the answer is the same for everyone. What is private is the fact that you asked, and when. RFC 9076, the IETF's survey of DNS privacy (it replaced the earlier RFC 7626 in 2021), sorts the people who can learn that fact into three groups, and the rest of this chapter is organized around them.

• On-path observers. Anyone who carries your packets: the Wi-Fi operator, your internet provider, a transit network, a government tap. With classic DNS they read every query and every answer. They can also forge an answer, because nothing in a plain UDP reply proves who sent it.
• The resolver operator. Your recursive resolver has to see the full question in order to answer it, and it sees your IP address. Encryption on the wire does nothing about this party: you are encrypting to it.
• The authoritative servers. On a cache miss, the resolver asks the root, then the top-level domain, then the zone's own servers. They see the resolver's address rather than yours, but historically each of them was sent the whole name.

The cheapest fix for the third group needs no encryption at all. QNAME minimisation (RFC 9156) has the resolver tell each authoritative server only as much of the name as that server needs to give a referral: the root is asked about example, the example servers about shop.example, and only the zone that actually holds the record hears www.shop.example. Chapter 3 walks through how that works step by step. The first two groups need cryptography, and that is where DoT, DoH and DoQ come in.

The first standard answer, DNS over TLS or DoT (RFC 7858, May 2016), is the most direct one. Take the DNS-over-TCP that has existed since the 1980s, where each message is preceded by a two-byte length, and run it inside TLS, the same encryption that protects HTTPS. Give it its own well-known port, TCP 853, so that a client knows to start TLS immediately instead of guessing. Nothing about the DNS message changes. The resolver unwraps the TLS layer and sees exactly the bytes chapter 2 takes apart.

TLS buys two things. Confidentiality: an observer sees a TLS session to port 853 and the sizes and timing of the records inside it, but not the questions. Integrity and authentication: if the client checks the server's certificate, a box in the middle can no longer slip in a forged answer, because it cannot produce valid TLS records for that session. That second half only works if the client actually checks, and that turns out to be the hard part.

A stub resolver usually learns its resolver as a bare IP address, from DHCP or router advertisements. A certificate is issued to a name. So what should the client check the certificate against? RFC 8310 (March 2018) answers with two usage profiles:

• Strict privacy. The client is configured with an authentication name, such as dns.example.net, or a key pin, and refuses to send any query unless the server proves it holds that name. If it cannot, resolution fails. That is safe and unforgiving: a captive portal at a hotel can break name resolution until you sign in another way.
• Opportunistic privacy. The client tries TLS on port 853. If the handshake works it uses it, ideally authenticating but carrying on if it cannot; if port 853 is blocked it falls back to plain port 53. This defeats a passive eavesdropper and costs nothing, but an active attacker who blocks port 853 or presents any certificate wins quietly.

Android's "Private DNS" setting is the most widely seen example of this split: give it a hostname and it runs strict DoT to that name; leave it on automatic and it tries the network's resolver over TLS opportunistically.

A dedicated port has a weakness: it is easy to see, and easy to block. A network that wants to force everyone onto its own resolver can drop TCP 853 and most opportunistic clients will quietly fall back to plain text. DNS over HTTPS, DoH (RFC 8484, October 2018), takes the opposite approach. It sends each DNS message as an ordinary HTTPS request to a URL such as https://doh.example/dns-query. On the wire that is TLS to port 443, the same as every web page. A network can still block a well-known DoH server by its address, but it cannot block DoH as a protocol without blocking the web.

The message itself is still the binary DNS message, unchanged, labeled with the media type application/dns-message. There are two ways to send it:

• POST: the message bytes are the request body. Simple and compact.
• GET: the message is encoded with base64url (the URL-safe alphabet from RFC 4648, with - and _ in place of + and /, and no trailing =) and placed in a URL parameter called dns. That makes the whole question part of the URL, so an ordinary HTTP cache can store the answer and hand it to the next person who asks the same question.

For GET caching to work, two identical questions have to produce identical URLs. That is why RFC 8484 says a DoH client SHOULD set the DNS message ID to 0: the ID was there to match a UDP answer to its question, and HTTP already does that job. The answer's cache lifetime comes from the smallest TTL in it, carried in the HTTP freshness headers. The DNS header carries the type; the HTTP layer carries everything else.

Because it is just HTTPS, DoH slots into software that already speaks HTTP. A browser can resolve names over the same HTTP/2 or HTTP/3 connection machinery it uses for pages, without asking the operating system. That is the source of both its popularity and its controversy, which the trade-offs section below comes back to. RFC 8484 recommends HTTP/2 as the minimum version, so many queries share one connection without waiting on each other.

DoT and DoH both ride on TCP, and TCP has two costs that classic DNS never paid. The first is set-up: a TCP handshake, then a TLS handshake, before the first question can go. The second is head-of-line blocking: TCP delivers bytes strictly in order, so if one packet is lost, every answer queued behind it waits for the retransmission, even answers that have nothing to do with the lost one.

QUIC (RFC 9000) is a transport built on UDP that fixes both. It combines the transport and TLS 1.3 handshakes into a single round trip, and it carries many independent streams in one connection, each delivered in order on its own, so a loss on one stream does not stall the others. HTTP/3 runs on it. DNS over QUIC, DoQ (RFC 9250, May 2022), puts DNS directly on QUIC on UDP port 853, with each query and its answer on a stream of their own. As with DoH, the DNS message ID must be 0, since the stream already pairs question and answer.

DoQ is also designed for more than the stub-to-resolver hop. The RFC explicitly covers resolver-to-authoritative traffic and zone transfers, places where a long-lived, low-latency encrypted connection with no head-of-line blocking is attractive. A client that has talked to the server before can use QUIC's 0-RTT resumption to send its first query in the very first packet, at the cost of some replay and privacy caveats the RFC spells out.

Encryption to the resolver moves your trust; it doesn't remove it. Your resolver still learns your address and every name you look up. You can choose a resolver whose privacy policy you like, but you have to take the policy on faith. Oblivious DNS over HTTPS, ODoH (RFC 9230, June 2022, published as Experimental), arranges things so that no single party has to be trusted with both facts.

There are two servers, run by different organizations. The client looks up the target resolver's public key and seals its DNS query for that key using HPKE, hybrid public-key encryption. It then sends the sealed query, over ordinary HTTPS, to an oblivious proxy, with the media type application/oblivious-dns-message. The proxy can see the client's IP address but only a sealed blob; it forwards the blob to the target. The target opens it, resolves the name and seals the answer with a key only that client can use, but it only ever sees the proxy's address.

The guarantee depends on the two operators not colluding, which is a policy assumption rather than a mathematical one, and on enough clients sharing the proxy that a single user cannot be picked out by timing. The cost is an extra hop on every query. The same split-trust idea, generalised to any HTTP request, became Oblivious HTTP (RFC 9458).

Encryption is useless if the client doesn't know that its resolver supports it, or under which name to authenticate it. For years the only answers were manual configuration or hard-coded lists in browsers and operating systems. Two standards from November 2023 let a network advertise its encrypted resolver properly.

Discovery of Designated Resolvers, DDR (RFC 9462), works from the resolver the client already has. The client asks that resolver, over plain DNS, for the SVCB records at the special name _dns.resolver.arpa. The answer lists the encrypted endpoints the resolver operator designates: their names, ALPN protocols (dot, h2, h3, doq), ports, and for DoH the URI path. In verified discovery, the client then connects to the designated name and requires that the TLS certificate cover the original resolver's IP address too, which proves that whoever runs the advertised server also controls the unencrypted one. If the original resolver is at a private address, no public certificate can cover it, so only opportunistic discovery is possible, and only when the designated resolver has that same IP address.

Discovery of Network-designated Resolvers, DNR (RFC 9463), carries the same information in the network's own configuration messages: new DHCPv4, DHCPv6 and IPv6 Router Advertisement options that hand the client an authentication name, protocol list and addresses at the moment it joins. That removes the first plain-text query DDR needs, but it trusts the local network's configuration channel, which is no stronger than the network itself.

The last stretch is the one from the resolver up to the authoritative servers. It is still almost entirely plain UDP, which matters less than the first hop because the resolver aggregates many users, but it is not nothing. RFC 9539 (February 2024, Experimental) describes how a resolver can, without any coordination, try DoT or DoQ to an authoritative server's address, remember which servers answered encrypted, and fall back silently when they don't. It defends against passive monitoring only; an active attacker can force the fallback. It is a deliberately modest first step, because authenticating authoritative servers at scale is an open problem.

Encrypted DNS closes one window. Several others stay open, and it helps to name them, because the most common overclaim about DoH is that it hides which sites you visit. It does not, on its own.

• Destination addresses. After the lookup, your device connects to the site's IP address, and every packet carries it. On shared hosting and big CDNs, one address serves thousands of sites, so the address alone is a weak clue; for a site on its own server it is a strong one.
• The server name in TLS. The opening message of a TLS connection, the ClientHello, normally names the site in plain text in the Server Name Indication field, so the server knows which certificate to present. Encrypted Client Hello (ECH) encrypts that name under a key the site publishes in its DNS HTTPS record (chapter 5), leaving only a shared public name visible. Note the dependency: ECH is only private if the lookup that fetched its key was private too.
• Sizes and timing. Encrypted messages keep roughly their original length. A name like a.example and one with a 60-character label produce visibly different packet sizes. EDNS padding (RFC 7830 defines the option, RFC 8467 the policy) rounds queries up to a multiple of 128 bytes and answers to a multiple of 468, which blurs that signal. Timing patterns remain.
• The resolver, and what it keeps. As above: encryption to a resolver is a decision to trust that resolver.
• Whether the answer is true. Authentication of the transport tells you that you are talking to the resolver you meant. It says nothing about whether that resolver was fed a forged answer upstream, or chose to rewrite one. Only DNSSEC validation (chapter 11) proves that an answer came from the zone's owner.

Plain DNS had an accidental property: whoever ran the network could see and steer it. Encrypted DNS removes that property, and some people relied on it on purpose.

• Network filtering. Schools, companies and parents often block malware and adult sites at the resolver they hand out. An application that sends DoH to a resolver of its own choosing quietly walks around that filter. The defensive answer is not to break encryption but to offer it: run an encrypted resolver, advertise it with DDR or DNR, and manage devices by policy rather than by watching the wire.
• Security monitoring. Defenders use DNS logs to spot infected machines calling home. When applications resolve over DoH to outside servers, those queries disappear from the network's view. Managed networks typically allow encrypted DNS only to their own resolver and log there.
• Split horizon. Many organizations answer internal names, such as intranet.corp.example, only from their internal resolvers, and some names resolve differently inside and out (chapter 10). A device that sends everything to a public resolver gets the outside view, or an NXDOMAIN, and internal sites stop working. Browsers handle this with fallback rules and enterprise policies; that is fragile, which is another argument for discovering the local resolver rather than bypassing it.
• Centralisation. When one browser ships one default DoH provider, a large share of the world's lookups can end up at a handful of operators. That trades many small, leaky observers for a few large, well-defended ones. Whether that is an improvement depends on whom you trust more, which is why the standards work moved toward discovering the network's own encrypted resolver.

Platforms expose this as a setting. Firefox, for example, documents several DoH protection levels, from off through a default that can fall back to the system resolver, to a strict mode that never does, and it turns DoH off by default on networks that signal they filter, using a "canary" domain the network can make fail. Mozilla's support page describes the current levels and exceptions. Public resolvers such as Cloudflare's 1.1.1.1 and Google Public DNS publish their DoH and DoT endpoints and privacy commitments in their documentation (sources below).

Modern versions of dig can speak DoT and DoH directly, which is the quickest way to see that a resolver answers over an encrypted transport. The commands and trimmed output below are illustrative, against a simulated resolver; substitute the name your provider documents. The output is the same DNS message you would get on port 53. Only the transport changed, and dig tells you which one it used on the SERVER line.

Two details are worth noticing. The ID is 0 in the DoH case, as RFC 8484 recommends, and the port changed from 853 to 443 without anything else in the answer changing. And the failed case is the strict-versus-opportunistic decision of RFC 8310 in miniature: what your client does next is a policy choice, not a protocol one.