DNS over HTTPS & TLS (DoH/DoT)

DoH vs DoT vs classic DNS, RFC 7858 and RFC 8484, privacy guarantees, enterprise interception challenges, and split-horizon compatibility.

Overview

Overview Classic DNS (RFC 1035, 1987) transmits queries and responses in plaintext over UDP/TCP port 53. Anyone on the network path — ISP, Wi-Fi operator, government — can observe which domains are queried. DNS over TLS (DoT) and DNS over HTTPS (DoH) address this by encrypting DNS traffic.

DNS over TLS (DoT — RFC 7858): - DNS queries sent over a persistent TLS connection on TCP port 853. - The resolver authenticates with a certificate (PKIX or DANE). - Traffic is distinguishable from other traffic (port 853 is DNS-specific). Network operators can identify and block or filter it. - Supported by: Android 9+ (Private DNS), Linux systemd-resolved (systemd 239+), Unbound, Knot Resolver.

DNS over HTTPS (DoH — RFC 8484): - DNS queries sent as HTTPS requests on TCP/443 (POST /dns-query or GET with dns= parameter). - Traffic is indistinguishable from normal HTTPS traffic — cannot be blocked without blocking all HTTPS to the resolver's IP. - Supported by: Firefox (uses Cloudflare DoH by default unless enterprise policy disables it), Chrome, iOS/macOS 14+, Edge. - Resolver URL examples: https://cloudflare-dns.com/dns-query, https://dns.google/dns-query.

DNSSEC vs DoH: different problem spaces. DNSSEC validates that DNS responses have not been tampered with (data integrity, not confidentiality). DoH/DoT encrypts the query/response channel (confidentiality from the network path). Both can be used together.

Enterprise challenges: corporate DNS filtering (Pi-hole, corporate resolver for internal domains) relies on intercepting port-53 DNS. DoH bypasses this — browsers sending DoH to Cloudflare never hit the corporate resolver. Enterprises must: detect DoH traffic (block DoH resolvers at firewall), deploy enterprise DoH resolvers, or use browser policy (DoH managed policy via MDM).

Key concepts

DoT (DNS over TLS)
DNS queries transmitted over TLS on TCP port 853 (RFC 7858). Traffic is encrypted and authenticated but distinguishable from other traffic by port number.
DoH (DNS over HTTPS)
DNS queries as HTTPS requests on TCP 443 (RFC 8484). Traffic is mixed with regular HTTPS, making it indistinguishable and resistant to blocking at the port level.
Oblivious DoH (ODoH)
Extension to DoH that routes queries through a proxy, so the resolver sees the client's query but not its IP, and the proxy sees the client IP but not the query. Cloudflare + Apple deployed ODoH.
Enterprise DNS policy
Browsers support DoH policy overrides via MDM/group policy. When a corporate DNS server is detected or policy is set, browsers disable DoH and use the configured resolver.
Canary domain
use-application-dns.net — Firefox queries this domain at startup. If it returns NXDOMAIN or SERVFAIL, Firefox disables DoH (indicating the network uses filtering that DoH would bypass). Corporate resolvers can serve this canary to disable Firefox DoH.

When to use it

  • Explaining why Firefox defaults to DoH and how enterprises can override it
  • Designing a privacy-preserving DNS architecture for users on public Wi-Fi
  • Debugging split-horizon DNS failures when browsers use DoH instead of the corporate resolver
  • Comparing DoH vs DoT for a mobile app DNS privacy requirement

Interview questions

  • What is the difference between DNS over TLS and DNS over HTTPS, and which provides more privacy?
  • How does DoH affect corporate DNS filtering and how do enterprises address it?

Sign up free to read the full topic

More Networking topics

Start free on Cariara · Coding problems · System design studio