dnsprobe v1

DoH (DNS-over-HTTPS) vs DoT — privacy and tradeoffs

· ~4 min read · dnsprobe.net/blog

Both DoH and DoT solve the same problem: the DNS query from your stub resolver to the recursive resolver is in cleartext over UDP/53, visible to anyone on the path. Your ISP sees every name you look up. A captive portal in a coffee shop sees the same. A nation-state intercepting at the AS boundary sees the same. Encryption at this hop closes that window. The two protocols differ in how they encrypt and, importantly, where the encrypted traffic looks like other traffic.

DoT — DNS over TLS, RFC 7858

Run a TLS connection to the recursive resolver on a dedicated port (853). Inside the TLS tunnel, the wire format is exactly the same as classic DNS (the DNS message format from RFC 1035). The TLS layer authenticates the resolver and encrypts the queries.

From a network-observability standpoint, DoT traffic is identifiable: it is on port 853. Network operators (corporate IT, ISPs, censors) can selectively block or allow it.

DoH — DNS over HTTPS, RFC 8484

Wrap each DNS query in an HTTPS POST or GET to a designated resolver URL (e.g. https://cloudflare-dns.com/dns-query). The DNS message is sent as the request body (POST) or in a query parameter (GET). The response is an HTTPS response carrying a DNS message body.

From the network's perspective, DoH is indistinguishable from any other HTTPS traffic on port 443. To block DoH you have to either (a) block the specific known resolver URLs, or (b) block all HTTPS, which breaks the internet.

The privacy difference

Both encrypt the query from your stub to the resolver. The resolver itself still sees every query you make — encryption does not change that. The difference is what an on-path observer can see about your DNS habits:

  • With cleartext DNS: observer sees every name.
  • With DoT: observer sees that you are doing DNS (port 853), volume of queries, timing patterns. Not the names.
  • With DoH: observer sees HTTPS on port 443. The fact that some of it is DNS is inferable from connection counts and timing but not directly visible.

The metadata distinction matters more than the names sometimes. An observer who knows you are sending 30 DNS queries per second to a known recursive resolver IP can still infer "this person is browsing". An observer who sees 30 HTTPS requests per second to one of thousands of HTTPS hosts has much less actionable signal.

The operations difference

Which is where the corporate IT teams come in. A network operator's view:

  • Cleartext DNS is auditable, filterable, and policy-enforceable. If a workstation is querying a known C2 domain, you can see it, log it, and route the response to a sinkhole. Most enterprise DLP and threat-detection products are built on this.
  • DoT is encrypted but identifiable. You can block port 853 at the firewall and force clients back to cleartext, where you can monitor again.
  • DoH is encrypted and not easily identifiable. Workstation clients can connect to a DoH resolver and the security team loses the visibility. This is why corporate group policies often disable DoH in Firefox and Chrome.

Mozilla's decision to enable DoH in Firefox by default (with Cloudflare as the resolver, in the US) in 2019 was the inflection point that put this debate into the corporate-IT mainstream. The position your team takes depends on whose privacy you are optimising for: the individual user against their ISP, or the security team against their users.

Performance

DoT adds one TLS handshake to the first query. DoH adds a TLS handshake plus the overhead of HTTP framing. Once warm, both protocols add a small but measurable latency cost (5-30ms per query, depending on the resolver's geographic distance) and an even smaller throughput cost.

HTTP/2 multiplexing on DoH actually helps if you are issuing many queries — a single connection serves all of them concurrently. HTTP/3 over QUIC is even better for lossy networks. The 0-RTT and connection-migration benefits described in the HTTP/3 post translate directly to encrypted DNS.

Configuration cheat sheet

systemd-resolved (Linux):

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes

cloudflared (the Cloudflare DoH client):

cloudflared proxy-dns --port 5053 \
    --upstream https://1.1.1.1/dns-query \
    --upstream https://1.0.0.1/dns-query

Then point your stub at 127.0.0.1:5053.

Browser-level DoH (Firefox, Chrome) overrides the OS resolver entirely. Useful for individual privacy; problematic in a managed environment because the corporate DNS filtering layer is bypassed.

What dnscheck does

Our resolver probes are deliberately cleartext UDP/53 to 1.1.1.1, 8.8.8.8 etc. The reason is that we need uniform, comparable answers across twelve different operators, and not every public resolver exposes the same response semantics over DoH. Cleartext gives us a like-for-like comparison. To verify your own resolver setup is using DoH or DoT, look at the connection on the wire (Wireshark filter port 853 or (tcp.port == 443 and dns)) or check the browser's "Secure DNS" status in chrome://net-internals or about:networking#dns.

References: RFC 7858 (DoT), RFC 8484 (DoH), Mozilla on enabling DoH by default.