How do DNS over TLS, DNS over HTTPS and DNS over QUIC differ in transport, port and message framing, and why would you choose one?

## One message, three carriers None of the encrypted transports changes the DNS message itself. The header, question, answer, authority and additional sections defined in RFC 1035 travel unchanged; what differs is the pipe around them. Classic DNS uses UDP port 53, with TCP on the same port for large responses and zone transfers - and RFC 7766 makes TCP support REQUIRED for DNS implementations. The three encrypted transports each take that message and put it inside something that provides confidentiality. ## Side by side | | DNS over TLS | DNS over HTTPS | DNS over QUIC | |---|---|---|---| | Specification | RFC 7858 | RFC 8484 | RFC 9250 | | Carrier | TLS over TCP | HTTP over TLS; HTTP/2 is the minimum recommended version | QUIC, whose handshake uses TLS 1.3 | | Default port | TCP 853 | Whatever the HTTPS URI template names, normally the HTTPS port | UDP 853 | | Framing | 2-octet length prefix, as DNS over TCP | `application/dns-message` body (`POST`) or base64url `dns` parameter (`GET`) | One stream per query, 2-octet length prefix | | DNS message ID | Used to match pipelined, out-of-order responses | SHOULD be 0, for HTTP cache friendliness | MUST be 0 | | Head-of-line blocking | Yes, one TCP byte stream | Yes whenever the HTTP version runs over TCP | No, streams are independent | | Scope in the RFC | Stub to recursive | Client to DoH server | Stub to recursive, recursive to authoritative, zone transfer | ## DNS over TLS DoT is the smallest change: open a TCP connection to port 853, run TLS, then send exactly what DNS over TCP would send - each message preceded by a two-octet length field. RFC 7858 forbids cleartext DNS on port 853, asks clients to **pipeline** several queries on one connection and to match responses that can come back out of order, and expects idle connections to be kept open and reused so the handshake cost is paid once. Its dedicated port is both its strength and its weakness: an operator can recognise it, measure it and allow it deliberately - or block it and push clients back to cleartext. ## DNS over HTTPS DoH treats a DNS query as an HTTP exchange. The client is configured with a **URI Template**; it either `POST`s the binary message with content type `application/dns-message`, or `GET`s the template with the message base64url-encoded in a `dns` variable. RFC 8484 requires servers to implement both methods, notes that `GET` is friendlier to HTTP caches, and asks clients to use a DNS ID of 0 because a varying ID would make identical queries cache separately. Consequences: - DoH traffic shares a port and a protocol with web browsing, so it is hard to single out; - it inherits HTTP features - connection reuse, multiplexed requests, caching, proxies; - an application can carry its own resolver choice, independent of the operating system. ## DNS over QUIC DoQ maps each query to its own client-initiated bidirectional **QUIC stream**. The client sends the length-prefixed message and closes its side of the stream; the server answers on the same stream and closes it. Because QUIC recovers loss per stream, one lost packet delays only the query it belonged to - RFC 9250 lists mitigation of head-of-line blocking as a design goal and aims for latency similar to classic UDP. The Message ID MUST be 0, since the stream already pairs query and answer. A resuming client may send queries in **0-RTT** data, but only replayable transactions - OPCODE `QUERY` or `NOTIFY` - and RFC 9250 flags the privacy cost of session resumption. It also reserves UDP 853 and mentions port 443 as a mutually agreed alternative that is less likely to be blocked. ## Choosing between them 1. **Must the network be able to see and govern encrypted DNS?** DoT on a known port is the easiest to recognise and allow. 2. **Must the lookup blend in and survive hostile middleboxes?** DoH rides ordinary HTTPS. 3. **Is latency under loss the constraint** - mobile links, many parallel queries, resolver-to-authoritative use? DoQ avoids head-of-line blocking and supports 0-RTT. 4. **What do the clients support?** Deployment breadth often decides more than protocol merit. Whichever you pick, the privacy caveats are shared: the resolver still reads the queries, and none of the three proves the data is genuine - that is DNSSEC's job.