Encrypted DNS: DoH and DoT

The previous lesson described a plain DNS lookup as a postcard: readable by anyone handling it along the way. Two IETF standards exist to put that postcard in an envelope: DNS over TLS (DoT, RFC 7858) and DNS over HTTPS (DoH, RFC 8484). Both encrypt the same lookup; they differ mainly in how they carry it.

DNS over TLS

RFC 7858 states its goal directly: “encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries”, addressing the fact that “nearly all DNS queries are sent unencrypted, which makes them vulnerable to eavesdropping by an attacker.” DoT uses its own dedicated port, 853, rather than the usual port 53. The RFC explains why: “this recommendation against use of port 53 for DNS over TLS is to avoid complication in selecting use or non-use of TLS and to reduce risk of downgrade attacks.”

DNS over HTTPS

RFC 8484 takes a different route: “each DNS query-response pair is mapped into an HTTP exchange”, carried over the same port 443 that ordinary HTTPS traffic uses. The RFC notes this has a side benefit: “the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter unprivileged on-path devices from interfering with DNS operations”, because a lookup is harder to single out and block when it looks like any other web request.

What encryption hides, and what it still does not

Both standards stop a network operator or Wi-Fi eavesdropper from reading your lookups in transit. Neither hides them from the resolver you sent them to. RFC 8484 is explicit that DoH does not change who the server itself can see: it notes that “various transports of DNS queries and responses do provide data that can be used to correlate requests”, and that ordinary web mechanics such as client IP addresses, cookies and TLS session information mean “DoH is not known to introduce new concerns beyond those associated with HTTPS” at the server end. RFC 7858 similarly notes DoT “does not address other security issues in DNS” and that “even with encrypted messages, a well-positioned party may be able to glean certain details from an analysis of message timings and sizes.” In short: encrypted DNS moves who sees your lookups back to the resolver operator you chose, it does not remove visibility altogether.

There is a second gap worth knowing about. Encrypting the DNS lookup does not by itself hide which site you then connect to: the TLS handshake that follows normally includes the hostname in plain view. As Cloudflare’s explanation of Server Name Indication (SNI) puts it, “SNI includes the hostname in the Client Hello message, or the very first step of a TLS handshake” — sent before encryption is established. An extension called Encrypted SNI (ESNI), the same source explains, “adds on to the SNI extension by encrypting the SNI part of the Client Hello”, which “prevents anyone snooping between the client and server from being able to see which certificate the client is requesting.” Support for hiding SNI still depends on both the browser and the site agreeing to it, and is not yet how every connection works.

How macOS supports it

Apple documents a DNS Settings configuration for Mac, iPhone and iPad that does exactly this: it lets a device “route a device’s DNS queries through an encrypted DNS server using DNS over HTTPS or DNS over TLS.” It is delivered as a configuration profile, which can restrict the encrypted resolver to specific domains through “supplemental match domains”, or apply only on certain networks using “on-demand rules” that can match things like the network’s SSID.