skip to content

When a client switches from plain DNS to DoH or DoT, what does encryption protect, and who still sees the names it looks up?

level: middleimportance: must knowfreq 40%

answer

  1. one hop, not the whole path
  2. the resolver still reads everything
  3. onward queries mostly in clear
  4. addresses and server names leak
  5. privacy is not authenticity

basics

~20 s

DoT and DoH encrypt only the hop between a client and its recursive resolver, hiding names from the local network. The resolver still sees every name, authoritative servers see its onward queries, and nothing proves the answers are genuine.

solid answer

~50 s

DoT (RFC 7858) and DoH (RFC 8484) put the **stub-to-recursive** hop inside TLS, so the Wi-Fi operator, the ISP or anyone else on that path can no longer read or alter the client's queries - RFC 7858 explicitly scopes itself to that hop. Names still leak to four places: the **recursive resolver**, which decrypts every query and sees the client's address; the **authoritative servers**, which receive the resolver's onward queries, usually as plain UDP - trimmed by QNAME minimisation (RFC 9156) but not hidden; an **on-path observer**, who sees the address the client connects to next and, unless it is encrypted too, the server name in the TLS ClientHello; and **traffic analysis** of sizes and timing. And encryption is not authenticity: RFC 8484 says the HTTPS connection does not provide the response integrity DNSSEC provides, so you are trusting the resolver.

go deeper

for a junior

Remember that DoT and DoH encrypt the conversation between your device and its resolver, and that the resolver itself still reads every name you look up.

for a middle

List the parties who still learn names - resolver, authoritative servers, the next connection's observer, traffic analysis - and state why encryption gives confidentiality but not data authenticity.

for a senior

Show you check whether the client authenticates its resolver or encrypts opportunistically, and that you pair encrypted transport with DNSSEC validation rather than treating either as sufficient.

for a principal

Frame resolver choice as a trust and logging decision: encrypted DNS moves visibility from the network operator to the resolver operator, and a policy should say which of the two you prefer.

## The hop that encryption covers A DNS lookup crosses at least two hops. The **stub resolver** on the client sends the question to a **recursive resolver**; the recursive resolver then asks the root, the TLD and the zone's **authoritative servers** until it has the answer. Classic DNS sends both hops as plain UDP on port 53, readable and alterable by anyone on the path. **DNS over TLS** (RFC 7858) and **DNS over HTTPS** (RFC 8484) encrypt the first hop only. RFC 7858 says so directly: it focuses on securing stub-to-recursive traffic and merely does not prevent future use for recursive-to-authoritative traffic. DNS over QUIC (RFC 9250) defines recursive-to-authoritative and zone-transfer use as well, but a client switching its own settings controls only its first hop. What the encrypted hop achieves: - the local network, the access provider and any on-path box can no longer read which names the client asks for; - they can no longer inject or alter answers on that hop without breaking the TLS session; - the client no longer sends cleartext port-53 queries for the network to log, as long as it does not fall back to them. ## Who can still see the name | Party | What it still sees | What reduces it | |---|---|---| | The recursive resolver | Every name, with the client's address and timing | Choosing whom you trust; nothing in the protocol hides the query from its own server | | Authoritative servers | The resolver's onward queries, usually plain UDP | QNAME minimisation (RFC 9156) sends each server only the labels it needs | | On-path observer after the lookup | The destination address the client connects to, and the server name in a TLS ClientHello if sent in clear | Encrypting the server name at the TLS layer, a separate mechanism | | Traffic analyst | Message sizes and timing, even when encrypted | Padding, such as the EDNS(0) Padding option that RFC 8484 cites | Two details in that table deserve emphasis. Authoritative servers see the **resolver's** address, not the client's - unless the resolver forwards a slice of the client's address in the EDNS Client Subnet option (RFC 7871), which exists for answer steering and gives some of that privacy back. And the recursive resolver is not hidden from at all: moving from the ISP's resolver to another operator's resolver moves the log, it does not delete it. ## Privacy is not authenticity Encryption proves the client is talking to a particular server and that nobody on the hop altered the bytes. It does not prove the **data** is what the zone owner published. RFC 8484 section 9 is explicit: the HTTPS connection provides transport security but not the response integrity of DNS data that DNSSEC provides, the two are independent and compatible, and a client either validates DNSSEC itself or trusts the DoH server to have done so. A resolver whose cache was poisoned upstream will deliver the forged record over a perfectly encrypted channel. ## Opportunistic versus authenticated resolvers RFC 7858 defines two privacy profiles: 1. **Opportunistic** - the client may learn of a TLS-capable resolver from an untrusted source and might not validate it. The RFC notes this maximises availability but provides privacy only when there are no on-path active attackers: an attacker who can block port 853 or impersonate the server can push the client back to cleartext or into its own hands. 2. **Out-of-band key-pinned** - the client already trusts a specific resolver key and refuses a server that does not present it. RFC 9250 refers to the later Strict and Opportunistic usage profiles (RFC 8310) for the same distinction. The practical question is always whether the client authenticates the resolver or merely encrypts to whoever answers. ## What this means when you choose encrypted DNS - Encrypted DNS protects **against the network**, not **from the resolver**; pick the resolver as deliberately as you would any service that sees your traffic. - It does not replace DNSSEC, and DNSSEC does not replace it: one gives confidentiality on a hop, the other gives origin authenticity for signed data. - A lookup's privacy is bounded by the connection that follows it - the address and any clear-text server name reveal much of what the query hid. - Configure authentication of the resolver, or accept that an active attacker can downgrade you.

  • What does QNAME minimisation add that switching the client to DoT or DoH does not?
    It works on the resolver's onward hop, which the client's encryption never touches. Under RFC 9156 the resolver sends each authoritative server only the labels it needs - a root server is asked about `com`, not the full name - so upstream servers learn less. It hides nothing from on-path observers of that hop, and it obsoletes the experimental RFC 7816.
  • Why can a DoT client using the opportunistic profile still lose its privacy on a hostile network?
    RFC 7858 section 4.1 says the opportunistic profile provides privacy only when there are no on-path active attackers. Because the client may not validate the resolver, an attacker can block port 853 so the client falls back to cleartext, or answer in the resolver's place. The out-of-band key-pinned profile closes that gap by requiring a known key.

saying these in an interview costs you the question

  • With DoH, nobody can see which sites I visit.
  • DoT encrypts the whole path from client to authoritative server.
  • An answer received over encrypted DNS is guaranteed to be the genuine record.
  • The DoH resolver cannot read the query because it arrives encrypted.
  • Switching to DoH removes the need for DNSSEC validation.