DoH vs DoT: What DNS Encryption Protects and What It Doesn't

Classic DNS sends queries unencrypted, almost always over port 53. RFC 7626, the IETF's analysis of DNS privacy, notes that such traffic can be seen by an eavesdropper like any other, and that an adversary who has watched a user's queries may be able to re-identify that user later from the pattern of queries alone, wherever they connect from. DNS over TLS (DoT) and DNS over HTTPS (DoH) were standardized to protect that first hop.

Which hop is protected

A lookup crosses several links: your device's stub resolver asks a recursive resolver, which in turn asks authoritative servers. RFC 7858 states that it focuses on securing the first of those links, stub to recursive resolver. DoH, defined in RFC 8484, covers the same link. In the deployments these RFCs target, both protect the content of the query and the answer on that link and nothing beyond it. RFC 7858 adds that nothing prevents the protocol from being applied between recursive resolvers and authoritative servers later.

DNS over TLS (RFC 7858, 2016)

DoT wraps ordinary DNS messages in a TLS session over TCP. Clients and servers use port 853 by default, and the RFC forbids using that port for unencrypted DNS. RFC 7858 defined two usage profiles: opportunistic privacy, where the client tries encryption without insisting on authenticating the server, and out-of-band key-pinned authentication, for clients that already trust a specific server. RFC 8310, which updates RFC 7858, generalized these into Strict and Opportunistic Privacy profiles. Strict refuses to proceed unless the connection is encrypted and the server is authenticated. Opportunistic attempts encryption and authentication but does not require them, so it can end in a cleartext connection and protects only against passive eavesdroppers, not an active attacker on the path.

DNS over HTTPS (RFC 8484, 2018)

DoH maps each DNS query and response onto an HTTP exchange. A client sends either a GET, with the DNS message encoded in base64url without padding in a dns query parameter, or a POST with the message as the request body. Servers must implement both, and the default media type, which every client and server must support, is application/dns-message. This is the RFC's own example, a query for www.example.com:

:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message

The dns value decodes to the same 33-byte wire-format query a classic resolver would receive, header included, so everything in Inside a DNS message applies unchanged. Two details are aimed at caching: GET requests suit HTTP caches, and clients should send a DNS ID of 0, because a varying ID would make equivalent queries cache separately. The RFC names HTTP/2 as the minimum recommended version; earlier versions can carry DoH but may perform very poorly.

What a network observer sees

Putting the three transports side by side shows what changes and what does not, from the point of view of someone watching your network connection, once an encrypted session is established (Strict mode, or Opportunistic mode with no active attacker).

What encryption does not hide

• The resolver sees everything. DoT and DoH move trust from the network path to the resolver operator, and queries are still tied to your address at that resolver. Choosing a resolver is a privacy decision as well as a speed decision.
• The next connection is visible. After the lookup, your device connects to the returned IP address, and the network can see that address. The server name is also normally visible in the handshake of the TLS connection that follows.
• Integrity of the answer is a separate problem. Transport encryption protects the link to the resolver. It does not prove the resolver's answer matches what the domain owner published; that is the job of DNSSEC, covered in DNSSEC explained.
• The rest of the path is out of scope. RFC 7858 concentrates on stub-to-recursive traffic. How a resolver then queries authoritative servers is a different question.

Trade-offs for networks and operators

DoT uses its own port, so a network can recognize it and decide whether to allow it. DoH shares port 443 with ordinary web traffic, which makes it harder to single out by port. RFC 8484 is explicit about the operational effect of encrypting the channel: filtering and inspection systems that rely on unsecured DNS transport will not work in a DoH environment, and a client's choice of DNS server can change the answers it gets, for example under split DNS. A network that depends on its own resolver for filtering or internal names needs to know which applications bring a resolver of their own.

Performance changes as well. Both transports need a TCP and TLS handshake before the first query, so connection reuse matters; RFC 7858 recommends that clients reuse an existing connection instead of opening one per query. A third transport, DNS over dedicated QUIC connections, was published as RFC 9250 in 2022. It offers encryption properties similar to TLS while avoiding the head-of-line blocking of TCP, and it uses UDP port 853.

What this means for lookups on this site

The tools on this site resolve names on the server, so your own device's encrypted-DNS setting does not change what they report. To see what your devices do, look for the Private DNS setting on Android, which uses DoT, and the secure-DNS options in browsers such as Chrome and Firefox, which use DoH.

Sources and further reading

• RFC 7626: DNS Privacy Considerations (Bortzmeyer, 2015)
• RFC 7858: Specification for DNS over Transport Layer Security (TLS) (Hu et al., 2016)
• RFC 8310: Usage Profiles for DNS over TLS and DNS over DTLS (Dickinson, Gillmor and Reddy, 2018)
• RFC 8484: DNS Queries over HTTPS (DoH) (Hoffman and McManus, 2018)
• RFC 9250: DNS over Dedicated QUIC Connections (Huitema, Dickinson and Mankin, 2022)