Encrypted DNS Hides the Lookup, Not the Connection

Encrypted DNS hides the DNS question and answer from a passive observer on the protected network path. By itself, it does not hide the resolver’s IP address, subsequent destination IPs, packet sizes or timing. The hostname may also appear in a separate TLS handshake unless Encrypted Client Hello (ECH) protects it.

The useful distinction is between reading a name from a packet, identifying an encrypted DNS flow, and inferring activity from metadata. Those are different levels of evidence.

Follow the lookup and the connection separately

Consider a client that uses encrypted DNS, then opens an HTTPS connection directly to a website. Assume the observer is on the client’s network path, outside the encryption endpoints, with no decryption keys or enclosing tunnel.

There are two exchanges:

1. Client → DNS resolver: the client asks for a record and receives an answer through an encrypted channel.
2. Client → website or CDN: the client connects to an address selected for the service. DNS encryption does not wrap this connection.

DNS over HTTPS (DoH) carries DNS in HTTPS exchanges. DNS over TLS (DoT) carries it through TLS, normally on TCP port 853. DNS over QUIC (DoQ) uses QUIC, normally on UDP port 853. All protect DNS message contents; their surrounding traffic remains observable.

Signal visible on the path	What it tells you	What it does not establish
Resolver destination IP	Which address the client contacts for the encrypted service	The queried name
Transport and ports	A clue to the protocol; TCP/853 suggests DoT, UDP/853 suggests DoQ	Confirmed DNS merely from a port number
Subsequent destination IP	Where the client sends application traffic	A unique website when multiple domains share that address
Visible TLS server name	The name offered in that handshake	A URL path, page contents or proof of a deliberate visit
Packet lengths, timing and direction	Flow duration, volume and request/response patterns	A directly decoded DNS question or exact browsing history

The IETF’s DNS privacy analysis explicitly describes residual risks from observable transport features and encrypted traffic sizes and timing. The ECH specification likewise identifies visible server IPs as a separate disclosure channel.

A hostname can reappear outside DNS

Without ECH, the Server Name Indication (SNI) extension in the TLS ClientHello can disclose the target domain—even with TLS 1.3. Encrypting the lookup does not encrypt that separate field. TLS 1.3 encrypts most of the remaining handshake, including the server certificate, but ordinarily leaves the ClientHello visible. RFC 9849 describes this gap.

ECH protects a private, inner ClientHello, including its SNI, while leaving a public outer ClientHello observable. When ECH is successfully used, the observer may see the provider’s public name rather than the private target name. The IP address and traffic pattern remain visible. Protection depends on the client having a compatible ECH configuration and the server accepting ECH—not merely on a browser supporting the feature. The ECH specification defines these conditions and the inner/outer handshake structure.

QUIC is not an automatic fix for this hostname disclosure. Its Initial packets are not protected with a secret key, so an observer with the necessary packets can recover the ordinary ClientHello they carry. ECH is still needed to protect the private name.

Also avoid saying that all headers stay plaintext. TLS over TCP leaves TCP fields such as sequence numbers visible, but QUIC protects its packet-number field and selected header bits. For Initial packets, that protection is removable by an observer; it does not provide the confidentiality of later encrypted packets. The outer IP and UDP information still exposes endpoints and ports.

For the application connection beyond name resolution, see what HTTPS hides in a packet capture.

Recognizing DNS is not recovering the query

DoH normally uses HTTPS port 443 and can share a connection with other HTTPS traffic. That makes classification harder, not impossible: a known resolver address or a distinctive traffic pattern can still provide clues. Conversely, an encrypted connection to a resolver address does not reveal its DNS payload. RFC 8484 discusses both connection sharing and traffic-analysis limitations.

DoQ makes this boundary especially clear: its specification does not attempt to conceal that the traffic is DNS. Its padding is intended to obscure the specific records being exchanged, not prevent protocol classification.

A June 2026 report on constrained-IoT research illustrates the distinction: researchers used surviving header information to identify DNS traffic. That is not the same as decrypting queries, and results from that wireless-device scenario should not be treated as a universal browser-history decoder.

Size and timing correlations can support probabilistic inferences. Caching, connection reuse, multiplexing, padding and background activity complicate interpretation. DNS requests themselves can also arise from prefetching or page resources rather than an explicit user action, as RFC 9076 explains.

The resolver still receives the question

Ordinary DoH, DoT and DoQ protect transport to the resolver; they do not conceal the question from that resolver. Its operator can process the queried names and associate requests with connection information. If your ISP operates the resolver you use, encrypting that connection does not hide those questions from the ISP in its resolver role. The DNS privacy considerations distinguish this operator visibility from passive observation on the wire.

DoH can also expose HTTP-layer correlation information to the service, depending on implementation. The DoH privacy considerations distinguish information visible on the wire from information available inside the server.

Capture location matters for the same reason. If a local DNS forwarder accepts plaintext queries and encrypts only its upstream connection, a capture between the client and forwarder can still contain readable DNS questions. The upstream capture has a different visibility boundary.

Check your own visibility without overreading it

Use only traffic and systems you own or are authorized to inspect. For a controlled test:

1. Record the boundary. Note which component performs encrypted DNS: browser, operating system or local forwarder. Identify whether your capture is before or after that component.
2. Verify the DNS leg. Compare configured endpoints with resolver or client logs. Treat ports and address ownership as leads, not payload confirmation. The encrypted-DNS detection workflow covers that distinction.
3. Inspect the separate application connection. In Wireshark, tls.handshake.extensions_server_name selects packets containing a decoded TLS server-name field. Inspect the enclosing handshake and destination address. Wireshark documents this field. An empty result does not prove ECH: the handshake may be missing or not decoded, or the client may be using an already-established connection. An ECH extension alone is also insufficient, because clients can send a dummy GREASE ECH extension.
4. Write down observations separately from interpretations. “The capture contains this SNI” is direct evidence. “This IP hosts these possible domains” is a mapping. “This pattern resembles a page load” is an inference.

Do not publish third-party packet data. Redact payloads, tokens, addresses and identifiers in anything you share; timing and size patterns can remain sensitive even after those redactions.