DNS-over-HTTPS vs DNS-over-TLS — the same goal, two very different deployments

The short version: classic DNS (the protocol from 1987) sends queries in plaintext over UDP port 53. Anyone on the network path can read every domain you're looking up, modify the responses, or block specific queries. DoT (RFC 7858, 2016) wraps DNS queries in TLS over port 853. DoH (RFC 8484, 2018) puts them inside HTTPS requests on port 443. Both fix the plaintext problem. They diverge on who controls the deployment, who can see the queries, and who can block them — and that's the question most people are actually asking when they ask "which one should I use." It depends on what you're protecting against.

What DNS encryption fixes — and what it doesn't

Before comparing the two, it's worth being clear about what either protocol is actually protecting. Classic DNS leaks every domain name your device looks up. Visit example.com, and your ISP — or any network operator in the path — can see the query for example.com, even before your browser sends the first HTTPS request. The actual content of that HTTPS request is encrypted; the DNS lookup that preceded it isn't. Encrypted DNS closes that specific gap.

What it doesn't fix: the destination IP address you connect to is still visible. The TLS Server Name Indication (SNI) field, in older TLS versions, also leaked the hostname during the handshake — though Encrypted Client Hello (ECH) addresses that in TLS 1.3. Encrypted DNS plus ECH closes the obvious leaks. Without ECH, encrypted DNS alone closes one leak but leaves the SNI leak open, which means the destination hostname is still visible during the TLS handshake. The honest framing: encrypted DNS is necessary but not sufficient.

How DoT works — dedicated channel on port 853

DoT (DNS-over-TLS, defined in RFC 7858) is the conceptually simpler design. Your device opens a TCP connection to the DNS server on port 853. It performs a TLS handshake — the same TLS that protects HTTPS — and then sends standard DNS queries inside the encrypted stream. The DNS server responds with standard DNS responses, also inside the encrypted stream. From the wire, all the network sees is a TLS connection to port 853.

Because port 853 is officially assigned by IANA exclusively to DoT, any TCP traffic on that port is unambiguously DoT. Network operators can identify DoT trivially — they don't need deep packet inspection, they just look at the destination port. If they want to block DoT, they drop port 853. If they want to allow it but log the destination DNS server's IP, that's also straightforward. DoT is honest about being DNS, which is a virtue for some use cases and a liability for others.

How DoH works — DNS hidden inside web traffic

DoH (DNS-over-HTTPS, defined in RFC 8484) takes a different approach. Your device sends DNS queries as HTTP POST requests (or GET requests with the query parameter) to a specific URL on the DNS provider's HTTPS server. The body of the POST contains a binary DNS message; the response body contains a binary DNS response. The whole thing happens over a normal HTTPS connection on port 443 — the same port your browser uses to load web pages.

From the network's perspective, a DoH request is indistinguishable from a regular HTTPS request to the same server. The connection looks like web traffic. The packet sizes look like web traffic (after the initial query, follow-up queries reuse the same HTTP/2 or HTTP/3 connection). The destination IP belongs to a generic-looking endpoint — Cloudflare's 1.1.1.1 or Google's 8.8.8.8 serve both DoH and other web traffic on the same IPs. To block DoH specifically, a network operator has to identify and block the specific endpoints, which is much harder than blocking a port.

Network visibility differences

The transport difference produces a visibility difference. With DoT, your network operator (corporate IT, ISP, school, hotel) can see that you're using encrypted DNS, can see which DoT server you're using (by destination IP), and can choose to block that server. With DoH, the network operator can see encrypted HTTPS traffic to the DNS provider's IP, but unless they specifically maintain blocklists of DoH endpoints, they can't distinguish DoH from regular HTTPS to that same provider.

This has predictable consequences. Corporate IT departments mostly preferred DoT for years because they can block it cleanly: drop port 853, and DNS falls back to the organization's resolver, which they monitor and filter. They tend to dislike DoH for the same reason — it bypasses their visibility. Consumer privacy advocates mostly prefer DoH for that same reason. Different stakeholders want different outcomes from the same architectural decision.

Which one networks can block

DoT is easy to block. Port 853 is the only thing using that port; firewall rule to drop it, done. Many enterprise networks already do. Many filtering firewalls in restrictive regions also do. If you configure a device to use DoT and that network blocks port 853, the device's DNS queries fail until the OS or app falls back to plaintext DNS — and most fall back silently.

DoH is much harder to block because the only way to block it is to identify and blocklist every DoH endpoint. Cloudflare's 1.1.1.1 is the most well-known and is usually on the blocklist; Google's 8.8.8.8 typically too. But independently-operated DoH endpoints proliferate — public lists like curl's DoH wiki catalog hundreds. A network operator who wants to block DoH globally has to keep that list current and accept that they'll always be one step behind new endpoints. Some restrictive networks try to detect DoH by traffic-pattern analysis (DoH has distinctive request-size and timing characteristics), but this is fragile and produces false positives.

The Mozilla DoH documentation explicitly cites this property — that DoH is hard for networks to block — as a deliberate design goal, not an accident. The same property makes DoH controversial in enterprise contexts, where the network operator considers DNS visibility to be a legitimate part of their security stack rather than a violation of user privacy.

Enterprise and parental-control implications

DNS-level filtering (the kind that powers most parental control software, corporate "safe browsing" filtering, and the simplest forms of malware-domain blocking) works by intercepting DNS queries and either dropping the ones for blocked domains or returning fake responses. We covered the mechanics in our writeup of how DNS-level filtering actually works.

Encrypted DNS bypasses this entirely — both DoT and DoH route queries to a different resolver than the local network's, so any filtering applied at the local resolver is moot. From the parental-control vendor's perspective, this is a problem. From the user's perspective, it depends entirely on whether they consider the filtering legitimate or invasive. Most enterprise endpoint-management tools now disable browser DoH by policy and rely on either OS-level DNS configuration or full traffic inspection to maintain visibility. Apple's MDM-managed iOS profiles include a DoH/DoT configuration mechanism designed exactly for this: the enterprise can specify an encrypted DNS resolver of their choice and prevent users from overriding it.

For households, the practical reality is that turning on DoH in a browser bypasses any router-based content filtering you've set up. That's either a feature or a bug depending on which side of the configuration you sit on.

Performance characteristics

DoT typically has slightly lower per-query overhead than DoH. Both protocols use TLS, but DoT sends a much smaller wrapper around each DNS message — there's no HTTP request line, no headers, no Content-Length, no HTTP method. The DNS message goes directly into the TLS stream. DoH, by contrast, wraps each DNS query inside an HTTP POST or GET, which adds tens to hundreds of bytes of overhead per query.

That overhead is mostly amortized away by connection reuse. Both DoT and DoH keep the TLS connection open across many queries, so the handshake cost is paid once. DoH on HTTP/2 multiplexes queries on the same connection, and HTTP/3 (over QUIC) further reduces latency. In practice, on a modern network, the two protocols produce indistinguishable latency for the user — single-digit milliseconds of difference at most. Don't choose one over the other for performance reasons; the choice is about visibility, control, and threat model.

DoT vs DoH at a glance

Which one should you use — three scenarios

"Which protocol is better" depends entirely on what you're trying to achieve. Here are three concrete scenarios with concrete answers:

Scenario 1: Personal device on hostile or untrusted networks

Coffee shops, hotels, airports, friend's Wi-Fi. The threat model is the local network operator observing or modifying your DNS. Either protocol works for the encryption itself; DoH is preferable because it's much harder for a hostile network to block. If you use DoT on a network that drops port 853, your queries silently fall back to plaintext on port 53 (most OS clients fail open this way) — and you've leaked everything you were trying to protect. DoH almost always reaches its endpoint.

Scenario 2: Home network with managed children's devices

You want the kids' devices to use a filtering DNS resolver (NextDNS, OpenDNS Family Shield, Cloudflare for Families) and you want them to be unable to bypass it. DoT is actually easier here — you configure the device to use a specific DoT resolver, and the kid can't trivially flip a setting in a browser to use a different DNS. Browser DoH can be disabled by enterprise/MDM policy or by setting the canary domain. The choice between DoT and DoH matters less than configuring the device-level DNS at the OS layer rather than letting individual apps choose.

Scenario 3: You're already running a VPN

If you're using a VPN, the local network can't see your DNS queries either way — the VPN tunnel encrypts everything, including DNS. The relevant question becomes which DNS resolver the VPN uses internally and whether it supports encrypted DNS to its upstream resolver. Most modern VPNs (including Casper's Cloak) use encrypted DNS internally and apply threat shield filtering at the resolver before sending the response back through the tunnel. In this configuration, DoT vs DoH is mostly an implementation detail; what matters is that the resolver isn't your ISP and isn't logging your queries.

The trust question that both protocols sidestep

Both DoT and DoH move trust from your local network operator to the encrypted DNS provider you choose. Cloudflare, Google, Quad9, NextDNS, ControlD — each of these companies sees every DNS query you send them. Encryption to them doesn't mean privacy from them. If your concern is that your ISP shouldn't see your DNS, encrypted DNS solves the problem. If your concern is that no third party should see your DNS, neither protocol helps; you need to run your own recursive resolver (which is its own project).

What you can demand from the resolver you trust: a clear logging policy, third-party audits, support for query minimization (so the upstream authoritative servers see only the parts of the query they need), and DNSSEC validation. The major public DoH/DoT providers all publish their policies; read them. Our deeper guide on this is in our 2026 DoH writeup.

Bottom line

DoT and DoH solve the same fundamental problem — DNS plaintext leaking your browsing destinations to the network — with two different architectural strategies. DoT is the honest design: a dedicated port, easy to identify, easy to manage, easy to block. DoH is the camouflaged design: hidden in HTTPS traffic, hard to identify without endpoint blocklists, hard to block at scale.

For consumers on hostile networks, DoH is the right choice because it's the one that actually reaches its endpoint. For enterprises that need DNS visibility, DoT is the more cooperative choice. For people running their own filtering DNS at home, DoT is more configurable and harder for users to bypass at the app level. For VPN users, the choice is mostly invisible — the VPN client handles it.

The real question is rarely "DoT or DoH" — it's "which resolver am I trusting, and what's its logging policy." Pick a resolver you trust, configure it system-wide (not per-browser), and verify with a DNS leak test that you actually got the configuration right. The protocol you use to talk to it matters less than the policy of the entity at the other end.