Encrypted DNS Transports and Their Trust Boundaries

Encrypting DNS does not change the protocol’s semantics by a single bit. The same message format, the same record types, the same resolution algorithm. What changes is the transport and, with it, who can see the query and who the client has to trust. Those two shifts are the entire subject, and they have consequences that are mostly social rather than cryptographic.

The same messages over three different pipes

DNS over TLS wraps the existing TCP framing, a two-octet length prefix followed by a message, inside a TLS session, conventionally on port 853. The messages are byte-identical to what TCP/53 carries. Because TLS provides a reliable ordered byte stream, the length prefix does exactly the job it does on plain TCP, and an implementation can reuse its TCP parser with a TLS socket underneath.

DNS over HTTPS carries the same message inside an HTTP request body. RFC 8484 defines two methods: a GET with the message in a base64url-encoded query parameter, and a POST with the raw message as the body and a media type of application/dns-message. The response is the raw DNS message in the response body with the same media type. There is no JSON envelope and no per-field mapping; the HTTP layer is a carrier.

DNS over QUIC places the message in a QUIC stream. The two-octet length prefix is retained because QUIC streams are byte streams, not message streams, and the framing has to be reintroduced. QUIC provides its own encryption and its own handshake, so DoQ has no TLS layer to configure separately, but it also means the transport is not a socket that existing TLS code can wrap.

Transport	Port	Framing	Underlying security
DoT	853/tcp	2-octet length prefix	TLS 1.2 or later
DoH	443/tcp	HTTP request/response	TLS via HTTPS
DoQ	853/udp	2-octet length prefix on a stream	QUIC (TLS 1.3 handshake)

The choice between them is mostly about what the surrounding network will carry. DoH uses the same port and protocol as ordinary web traffic, which is why it traverses networks that block or intercept port 853. That property is also why it is harder to distinguish from browsing and harder for a network operator to apply policy to.

What each layer actually hides

Encryption hides the query name and type from anyone observing the path between client and resolver. It does not hide the fact that a connection to a resolver exists, and it does not hide the volume or timing of queries. An observer who can see connection metadata learns that a client talks to a particular resolver, how often, and how large the responses are. For DoH, the connection is shared with other HTTPS traffic, which makes the inference weaker but not absent.

It does not hide anything from the resolver itself. The resolver sees every name in plaintext because it must, in order to resolve it. This is the central trade: moving the observation point from the network to a small number of resolvers. A public resolver sees the queries of every client that uses it; the network operator who used to see them sees only that a TLS connection exists.

That shift is why query name minimisation matters more, not less, under encryption. A resolver that sends the full name to the root, the TLD, and the authoritative server exposes the name to three parties it does not control, regardless of how the client reached it. Minimisation, described in Iterative Resolution: Walking the Tree from Root Hints to Answer, reduces each of those exposures to the suffix that server needs. Encryption and minimisation address different hops: encryption protects client to resolver, minimisation protects resolver to authority.

Encrypted transports also do not protect against a resolver that is dishonest or compromised. A client that trusts a resolver’s answers is trusting it to return correct data, and encryption authenticates the channel, not the content. DNSSEC is the mechanism that authenticates content, and the two are complementary rather than redundant: DNSSEC tells a client whether an answer is genuine regardless of who carried it, while encryption tells a client that nobody on the path modified or observed the exchange. Neither substitutes for the other, and a deployment with one and not the other has a gap that is easy to describe precisely.

Authentication is the part that needs configuration

A TLS connection to a resolver authenticates the resolver’s certificate. The client must know which name to expect in that certificate, which means it must have been configured with a resolver hostname rather than only an IP address. That is a real change from plain DNS, where a resolver is identified by an address and nothing else.

The bootstrap problem follows. A device that has just joined a network needs an IP address (via DHCP or stateless autoconfiguration), a resolver address, and, for encrypted transport, a resolver name and a trust anchor for the certificate. All of it arrives before any DNS query can be made, so none of it can be fetched by DNS. DHCP options carry resolver addresses; the resolver name and any pinned certificate information have to come from the same out-of-band channel or from the device’s firmware. A device that can only learn its resolver by name, and learns the name over an unauthenticated channel, has not improved its position much.

RFC 8310 addresses this by defining usage profiles, of which the two that matter are opportunistic and strict. The strict profile requires successful authentication of the configured resolver, by a certificate chain for its name or a pinned key, and forbids falling back to cleartext: if the TLS session cannot be established, the lookup fails. The opportunistic profile attempts encryption and authentication but does not require either, and it may fall back to cleartext when the resolver does not support TLS; it exists because a device that fails closed on such a network has no DNS at all. When encryption is actually in use, the profile raises the cost of passive observation, but it does not stop an active attacker who can present any certificate, and a cleartext fallback offers no protection at all. The distinction is worth being explicit about in any deployment: opportunistic encryption raises the cost of passive surveillance and does not stop an attacker who controls the path.

Pinning a certificate or a public key removes the dependence on the public certificate authority system, at the cost of having to update the pin when the certificate rotates. A resolver that rotates on a short schedule forces frequent firmware or configuration updates, which is why pinning is usually applied to a long-lived key rather than to the leaf certificate.

Connection reuse changes the failure and latency profile

All three transports are connection-oriented, and all three expect many queries per connection. This is a structural change from plain UDP, where each query is independent and a lost packet costs one retransmission.

A TLS handshake costs one or two round trips before the first query, so the first lookup over a new connection is slower than the same lookup over UDP. Subsequent lookups on the same connection cost one round trip each, which is comparable to UDP for a warm path and better than TCP for repeated queries, since TCP’s handshake is also avoided. A connection carrying one query is slower than plain UDP because it pays a handshake UDP does not; a connection carrying many amortises that cost and avoids a TCP handshake per query.

The failure profile changes with it. A TCP or QUIC connection that goes away takes every in-flight query with it, and a client must detect the closure and re-establish. With UDP, a lost query is a timeout on that query alone. The practical consequence is that an encrypted resolver client needs connection state, a reconnect policy, and a timeout that distinguishes “the connection is dead” from “the answer is slow”, which is a nontrivial amount of code compared with a UDP socket that sends and waits.

The multiplexing in DoQ is the mechanism that avoids head-of-line blocking. Each query goes on its own stream, so a slow or lost response does not delay the others on the same connection. Over TCP-based transports, a lost segment blocks every subsequent message until it is retransmitted, because TCP’s ordering guarantee is connection-wide. That is the reason QUIC’s stream model is a better fit for a query-response protocol, and it is the same reason HTTP/2 and HTTP/3 moved to streams for the analogous problem.

The policy problem that encryption creates

A network operator who wants to block a domain, or to redirect it to a local address, relies on seeing the query. Encrypted DNS removes that visibility, and the operator’s remaining options are to block the resolver’s address, to block the transport by port, or to require a local resolver that the client is forced to use.

Each of those is a blunt instrument. Blocking port 853 is straightforward; blocking DoH on 443 is not, because it is indistinguishable from other HTTPS traffic to the same address without inspecting the TLS server name, which itself requires an interception proxy. A proxy that terminates TLS and re-originates it can see the queries, but it must install a trust anchor on the client, which is a significant change in the client’s security posture and one that a client can detect.

The response from the protocol side has been to make the encrypted transport the default where possible and to add mechanisms that let a client and a resolver negotiate policy explicitly rather than through interception. Those mechanisms are still about policy between two consenting parties; none of them gives a network operator visibility into a client’s queries without the client’s cooperation.

The other side of the policy problem is that a resolver now sees a large fraction of a population’s queries, which makes it a surveillance point in its own right. The mitigations are structural: minimisation reduces what is forwarded, and a resolver that does not log reduces what it retains. Neither is a protocol guarantee, and a client cannot verify either from the outside. The observable property is only that the channel is encrypted, which is a much weaker statement than “the query is private”.

Where the record layer still matters

Encryption does not change any of the semantics covered elsewhere in this cluster. A truncated response still means retry over a transport that can carry the whole message; DoT and DoQ already use transports whose message limit is 65,535 octets, so truncation there indicates a server-side limit rather than a datagram limit. Negative answers still carry the SOA and are still cached under the same rules. The delegation structure is unchanged, so a resolver reached over TLS still walks the same tree and still depends on glue.

What encryption does change is the value of the in-band defences against off-path forgery. Transaction ID randomisation and source port randomisation exist because a UDP query can be answered by anyone who guesses them. On a TLS connection, the response arrives on an authenticated channel, so those defences are no longer load-bearing for that hop. They remain load-bearing for the hops the resolver makes on its own behalf, which are still plain UDP to authoritative servers. That asymmetry is the practical summary: the client-to-resolver hop is protected, the resolver-to-authority hops are not, and the resolver is the party that sees the plaintext of both.

The chain of trust described in DNSSEC Validation and the Chain of Trust is what covers the unprotected hops. A validating resolver can be fooled about which server it is talking to and still return a correct answer, because the signature travels with the data. A non-validating resolver behind an encrypted channel has a secure path to a party whose answers it cannot verify, which is a precise description of the trust it is placing and the reason the two mechanisms are usually deployed together.