Encrypted DNS: Privacy vs. Anonymity

Putting DNS inside an encrypted connection changes who can read the query, but it doesn’t make the query anonymous. The two get conflated constantly, and the difference decides what encrypted DNS actually buys you.

DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ) protect DNS messages between a client and a resolver. When the client authenticates the resolver it intended to reach and doesn’t fall back to plaintext, that connection stays confidential and tamper-resistant. The resolver at the far end still has to receive the question to answer it.

Plaintext DNS exposes the question twice

Traditional DNS sends queries over UDP or TCP with no encryption. A query for www.example.com A is readable by anyone able to observe the network path, whether that’s a local access network, an ISP, an enterprise gateway, or something in between. An on-path network can go further than reading. Unencrypted queries can be silently redirected to a different resolver entirely, with the answer dressed up to look like it came from the one the client chose.

The query also reaches the recursive resolver, which needs the name to do its job. RFC 9076 treats those as separate risks, one on the wire and one in the server, and encryption only addresses the first.

Encryption protects the path to the resolver

DoT carries DNS over TLS on a dedicated port, DoH maps queries into HTTPS exchanges, and DoQ carries DNS over QUIC. Used with an authenticated server and no insecure downgrade, all three keep DNS contents away from observers on the protected path.

An observer between client and resolver can still see that the two are communicating. What it can no longer do is read the question and answer as plaintext. This protects the message on that hop, but it doesn’t prove the DNS data is genuine. Authenticating the answer itself is the job of DNSSEC.

The resolver still sees the query

Encryption ends at the encrypted DNS service, which decrypts the request because it needs the question to answer it. The service receives both the peer address and the query, because it’s the endpoint:

Client
  |
  | encrypted DNS
  v
Encrypted DNS service   <- decrypts here; sees peer address + query
  |
  | resolution continues
  v
Authoritative DNS

That peer address isn’t necessarily a person, since NAT, VPNs, proxies, and shared systems all muddy attribution, though cookies, account data, or external datasets can re-attach identity depending on the deployment. RFC 8484 notes that the DNS wire format carries no client identifier, but the transports underneath it, starting with the IP layer, provide information that can correlate requests.

So encryption removed the path exposure and left the server exposure intact, and resolver choice becomes part of the privacy model. A real privacy evaluation asks who runs the service, what it receives, what can be correlated, and what its data-retention policy is, which is why RFC 8932 sets out best practices for operators of DNS privacy services.

Resolution also continues past the encrypted hop. A recursive resolver still contacts other servers when it has no cached answer, and encrypting the client leg doesn’t require the resolver’s onward queries to authoritative servers to be encrypted too. QNAME minimization (RFC 9156) trims what intermediate servers learn by withholding unnecessary labels, but the authoritative server responsible for the record still receives the full name in the end.

Metadata survives the encryption

Encryption hides content far better than it hides the fact of communication. A path observer still sees packets moving between addresses, along with sizes, timing, and connection reuse, and RFC 9076 notes that traffic analysis of encrypted DNS is possible when those characteristics can be correlated with DNS activity seen elsewhere. Because DoH rides on HTTP, the DoH endpoint also receives HTTP-layer metadata, and cookies, headers, and connection reuse can become server-side correlation handles if an implementation uses them.

Encryption, privacy, and anonymity are three different questions

The word people reach for is usually “privacy,” but three separate properties get bundled under it:

Encryption is a mechanism. Privacy is a property of the whole system and how it’s operated. Anonymity is the hardest of the three to achieve, and RFC 6973 defines it relative to a specific observer, where a person can be anonymous to one party and fully identifiable to another. That’s why “encrypted DNS makes you anonymous” is too loose to mean anything technically useful.

Oblivious DoH splits the address from the query

Ordinary encrypted DNS doesn’t try to separate the client-facing connection from the server reading the query. Oblivious DNS over HTTPS (ODoH) does. It puts a proxy between client and target. The client encrypts the DNS message to the target’s public key and sends it through the proxy. The proxy sees the client connection but can’t decrypt the message. The target decrypts the query and gets it answered, but receives it through the proxy rather than directly from the client.

Client  ->  Oblivious proxy  ->  Oblivious target  ->  DNS resolution
            (sees address,        (reads query,
             not the query)        not the address)

RFC 9230’s stated goal is to prevent any single server from knowing both the client IP address and the query contents, and that guarantee depends on the proxy and target not colluding.

ODoH is an Experimental RFC, and it shouldn’t be sold as universal anonymity. It splits two facts between two roles, and other network metadata, application traffic, account information, or cooperating observers can still re-link activity.

Who wants what from encryption

On a managed enterprise network, the goal is usually integrity and control. An authenticated, encrypted connection to a chosen resolver stops an attacker on that path from reading, modifying, or spoofing answers, and the NSA’s enterprise guidance and NIST SP 800-81r3 recommend it for that reason, with OMB M-22-09 requiring encrypted DNS for U.S. federal civilian agencies wherever it’s technically supported. The same guidance warns that browsers and applications enabling DoH to an outside resolver can bypass enterprise filtering, logging, and split DNS, so enterprises want endpoints pointed at a chosen, policy-enforcing resolver with unauthorized encrypted resolvers blocked.

For an individual, the usual goal is hiding DNS from the local network or ISP. Pointing a device at an external encrypted resolver delivers that much, since the network’s own DNS servers stop seeing queries and a path observer can’t read them. What it doesn’t do is conceal where you go. The chosen resolver now sees every query, the device still connects to the resolved address where the local network can watch it, and without Encrypted Client Hello the TLS handshake usually carries the destination hostname in the SNI field anyway. A VPN moves the observation points rather than removing them, hiding the destination from the local network while handing the VPN operator that view.

The same confidentiality cuts the other way for networks that want visibility. When an application sends DoH straight to an external resolver, a local resolver that used to see those queries no longer does, which affects troubleshooting, DNS-based filtering and policy, and malware analysis. Privacy and operational visibility are different objectives, and the real question is always which observer should be trusted with which information.

Summary

Encrypted DNS protects DNS messages on the path to the resolver. The resolver still receives the query and the connection that carried it, so resolver choice matters as much as the encryption.

Anonymity is the harder question, and ordinary encrypted DNS doesn’t answer it, because one server still sees both the peer address and the query. ODoH is the transport built to separate the two, and even then the connection that follows is visible to whoever can watch that path. Encryption closes one observation point, but it doesn’t make DNS activity disappear.