Both protocols encrypt DNS queries between your device and a resolver. The core difference is how visible that traffic is to the network in between — a trade-off between user privacy and network manageability.
| Feature | DoH (DNS over HTTPS) | DoT (DNS over TLS) |
|---|---|---|
| RFC | RFC 8484 | RFC 7858 |
| Port | 443 | 853 |
| Transport | HTTPS (TLS + HTTP) | TLS directly |
| Traffic visibility | Blends with HTTPS; hard to isolate | Dedicated port; easy to identify |
| Network blocking | Hard to block without wide impact | Block port 853 to deny all DoT |
| Operator monitoring | Difficult | Straightforward |
| Encryption scope | Stub resolver to recursive resolver only | Stub resolver to recursive resolver only |
| Typical adopters | Browsers, consumer apps | OS resolvers, enterprise configs |
DNS over HTTPS wraps each DNS query inside an ordinary HTTPS request. Because it uses port 443 — the same port as all other HTTPS web traffic — the DNS query is indistinguishable from a visit to a website at the network level. A passive observer or firewall cannot tell whether a given HTTPS connection carries a DNS query or any other application data. Because DoH shares port 443 with all other HTTPS traffic, networks cannot block it by port alone. Blocking DoH means either IP-blocking the known addresses of public DoH resolvers, or identifying resolver hostnames via the TLS SNI field — and even that lever is closing as Encrypted Client Hello (ECH) deployment grows.
DNS over TLS opens a dedicated TLS connection on port 853 and sends raw DNS messages over it. The content of the query is encrypted, but the fact that port 853 is in use clearly identifies the traffic as DNS. Network operators can therefore monitor how often DNS queries happen, block DoT entirely by denying port 853, or route DoT traffic to a different resolver.
The core tension between DoH and DoT is not about encryption strength — both use TLS and both protect query content equally well. The difference is in who controls the DNS channel.
DoH favors the end user. Because queries are hidden inside HTTPS, a network cannot silently redirect or intercept them without breaking all HTTPS traffic. This is valuable for users on untrusted networks (public Wi-Fi, ISPs that historically injected ads into DNS responses).
DoT favors network operators. An enterprise security team that needs to enforce DNS filtering or monitor for malicious lookups can do so by blocking port 853 and running their own DoT resolver, keeping users on the corporate resolver. The same is true for parental control systems and compliance environments.
Both DoH and DoT encrypt only the stub-resolver to recursive-resolver hop — the connection between your device and whatever DNS service you have configured. The recursive resolver still queries authoritative nameservers using standard DNS unless those nameservers also support encrypted transport. The full resolution chain is not end-to-end encrypted by either protocol.
For consumer-facing applications and browsers where user privacy is the priority, DoH is the natural fit. It requires no special port exceptions and degrades gracefully through firewalls. For operating systems and enterprise environments where network operators need to maintain visibility and control over DNS traffic, DoT is preferable: its dedicated port makes it trivial to identify, inspect, and selectively route.