Encrypted DNS changes who can observe a query

DNS over TLS protects a DNS channel using TLS; DNS over HTTPS carries DNS exchanges through HTTPS. In each case, the client must authenticate the intended resolver endpoint under the applicable configuration rather than accepting any encrypted connection. A malicious or mistakenly trusted resolver can still see queries and provide misleading answers within whatever validation constraints the client applies. Using an encrypted transport to that resolver does not establish that it follows a particular logging or retention policy.

The encrypted client-to-resolver leg also does not automatically encrypt every later resolver-to-authority interaction. Network observers can still see connection metadata, packet timing, and other traffic, while application connections made after resolution reveal additional information. Bootstrap configuration deserves care: the client needs a trustworthy way to identify and reach the intended resolver without accepting an attacker-supplied endpoint as its new authority. Document the chosen resolver, verification identity, fallback behavior, and which network legs the deployment actually protects.

DNSSEC provides mechanisms for authenticating signed DNS data and authenticated denial within its validation model; it is not a query-encryption protocol. Encrypted DNS transport can hide query content on a protected leg without making an unsigned answer cryptographically authenticated as zone data. A deployment can combine these mechanisms, but it must state where validation occurs and whether the client trusts a resolver's assertion or validates independently. A correct record still does not authorize an application action or prove the returned address serves a healthy endpoint.

Oblivious DNS over HTTPS introduces a proxy and target arrangement intended to separate client identity from query content under non-collusion and configuration assumptions. The proxy can observe client-side metadata while the target processes the decrypted DNS query; collusion or correlating observations can undermine the hoped-for separation. It should not be described as universal anonymity or protection from every timing observer. Name the adversary and the parties trusted not to combine their views before attributing a privacy property to the arrangement.

A forwarding resolver's cache can answer repeated questions without contacting its upstream resolver again. That reduces upstream queries but does not undo the local resolver's receipt of each incoming question. A privacy analysis that counts only upstream packets can therefore overlook logging at the first recipient. Cache keys, negative answers, lifetimes, and application behavior also affect real hit rates. Any numerical savings must identify where the cache sits and which observer's evidence changes.

Use the deterministic cache lab for a narrow working-set comparison. Reset, set both C=4 and s=4, predict twelve hits in the sixteen requests already evaluated at time zero, then inspect and Play or Step to extend the trace. Reset and set both C=3 and s=4 for a separate zero-hit initial case. Editing controls retains elapsed time; Reset is what returns to the initial sixteen-request evaluation. This LRU model has no DNS names, TTLs, negative answers, encryption, or observer logs. It illustrates reuse capacity only, not an end-to-end DNS privacy measurement.