DNS over HTTPS vs DNS over TLS: Which Should You Use?

DNS over HTTPS vs DNS over TLS is a contest between two protocols that both encrypt your domain lookups, so the deciding factor is transport, not crypto. DoH hides queries inside ordinary HTTPS web traffic on port 443, while DoT runs them over a dedicated TLS connection on port 853 that any network observer can label instantly. That single difference drives everything else: visibility, blocking, setup, and which one survives a hostile network.

Both standards come from the IETF, and both are recent. DNS over TLS arrived first, standardized in RFC 7858 and published in May 2016 (RFC 7858, 2016). DNS over HTTPS followed in RFC 8484, published in October 2018 (RFC 8484, 2018). DoH grew partly out of DoT's weakness: a dedicated port is trivial for a firewall to identify, while HTTPS on port 443 is expected traffic that filtering would break the web to remove (Wikipedia's DNS over HTTPS entry).

Key Takeaways

• DoH and DoT both encrypt DNS; the split is transport, port 443 (DoH) versus port 853 (DoT).
• DoT is easy to block with port filtering; DoH rides inside HTTPS where port 443 must stay open.
• Neither stops browser-level leaks: 84% of 283 Android VPN apps leaked DNS in a 2016 study.
• Pick DoT for a clean privacy posture, DoH for circumvention, and re-test after switching.

DNS over HTTPS vs DNS over TLS: The Short Answer

Short answer: both encrypt your queries, and the real choice is visibility versus circumvention. DoH packages DNS inside HTTPS on port 443, indistinguishable from web browsing at the port level, while DoT uses a dedicated TLS stream on port 853. Cloudflare documents both transports for 1.1.1.1, with DoH served from a standard HTTPS URL that any client can call (Cloudflare's DoH docs).

DoH takes a wire-format DNS message and wraps it in HTTP, normally a POST or GET, inside a standard HTTPS session. RFC 8484 defines the encoding, including the application/dns-message media type (RFC 8484, 2018). DoT sends the same wire-format message over a raw TLS connection with no HTTP layer at all, exactly as RFC 7858 specifies (RFC 7858, 2016). One protocol looks like an API call; the other looks like what it is.

DoH's adoption led the way in browsers, while DoT became the default on Android's private DNS setting and on many routers. Wikipedia's DoH article traces the provider adoption and the controversy around encrypted DNS, including ISP objections that it shifts visibility from the network to a third-party resolver (Wikipedia's DNS over HTTPS entry). Neither protocol makes you anonymous. Both are transport encryption for the same old question: which site you are about to visit.

	DNS over HTTPS (DoH)	DNS over TLS (DoT)
Port	443, shares HTTPS	853, dedicated
Visibility	Looks like web traffic; SNI and the resolver IP are visible, and the resolver still sees the query	Instantly identifiable TLS connection on a known port
Blocking	Hard to block where HTTPS is allowed	Easy to block with port 853 filtering
Setup	Browser or OS setting; pick a DoH resolver URL	OS-level or router config; point at a DoT server
Best for	Censorship resistance and locked-down networks	Clean privacy posture, enterprise filtering, low overhead

Read the table as a decision, not a spec sheet. DoH wins where networks allow HTTPS but police everything else. DoT wins where you want a transport that says what it is and stays filterable by design. The sections below unpack each row and add the caveats both protocols share.

DNS over HTTPS vs DNS over TLS: How They Differ

The two protocols share an encryption goal and little else in the field. The differences line up into three buckets: ports, visibility, and blocking, and each one changes the answer to which protocol you should run.

Ports: 443 versus 853

Port 853 was assigned to DNS over TLS and published in RFC 7858 in May 2016 (RFC 7858, 2016). Port 443 belongs to HTTPS itself, the port every browser already uses. DoH reuses that infrastructure, so blocking DoH means filtering the web; blocking DoT means adding one firewall rule.

Those two ports explain the adoption gap. DoH could ship as a browser feature with no operating system changes, because the HTTP stack already existed. DoT needed OS support or a router upgrade, which is why it arrived as a system setting on Android and Windows later, and why DoH went mainstream first.

What a network observer sees

DoT is visible on the wire. A middlebox sees a TLS connection to a known resolver IP on port 853 and labels it DNS, so the network knows every time you resolve a name, even if it cannot read the query. DoH looks like a request to a web API, but visible is not the same as invisible. The resolver's IP address is well known, and the TLS Server Name Indication can expose the resolver hostname.

Wikipedia's overview of DoH is blunt about the boundary: the protocol changes what an on-path observer can see, but the resolver you choose still sees every query (Wikipedia's DNS over HTTPS entry). Neither protocol is anonymous DNS. Both are private transport.

Performance and overhead

DoT opens one persistent TLS connection per resolver and reuses it, which keeps per-query overhead low. DoH stacks HTTP on top of TLS, so early implementations paid a latency cost until connection reuse and HTTP/3 arrived. On modern stacks the difference is noise for everyday browsing.

DoH over HTTP/3 rides QUIC and multiplexes well, and resolvers such as Cloudflare's document the setup (Cloudflare's DoH docs). Benchmarks that show DoT beating DoH usually predate HTTP/3. Optimize for your threat model, not for single-digit milliseconds.

Blocking and censorship contexts

This is where the two protocols diverge hardest. A firewall blocks DoT by dropping traffic to port 853, and because the port is dedicated, the filter is cheap and effective. DoH defeats that by design: it rides port 443 and the same TLS profile as ordinary web traffic, so port-based filtering cannot touch it.

Wikipedia's DoH article documents the resulting arms race, including state-level attempts to fingerprint DoH servers and Oblivious DNS, which adds a second hop so the resolver cannot see the client's address (RFC 9230). In networks that allow any HTTPS, DoH generally gets through. In networks running deep packet inspection that fingerprints TLS by handshake shape, neither protocol is safe.

DNS over HTTPS or DNS over TLS: Which Should You Use?

Choose DoT when you control the network path and want a clean, identifiable privacy transport. Choose DoH when the network itself is the adversary. Browser support tipped early to DoH, with Firefox enabling it by default in 2019, Chrome following in 2020, and Windows 11 later shipping its own client, a timeline Wikipedia's DoH article records (Wikipedia's DNS over HTTPS entry).

When DoT wins

DoT suits the privacy purist who runs their own resolver or keeps DNS inside a VPN tunnel. One port, one rule, no per-application configuration: point the system resolver at a DoT server and every lookup on the device goes through it. DoT is also easier to audit, because the dedicated port makes the encrypted channel obvious in packet captures. If your threat model is an ISP logging plaintext DNS, DoT closes it.

When DoH wins

DoH wins under censorship and in networks that allow HTTPS but filter everything else. Because it looks like web traffic on port 443, it can reach a resolver where DoT cannot, and providers such as Cloudflare document DoH endpoints built for browsers and applications alike (Cloudflare's DoH docs). The cost is that the browser now owns the DNS decision.

Chrome and Firefox each ship their own DoH clients and defaults, which means your system-level DoT configuration can be silently bypassed by the browser in front of you. Our explainer on the protocol covers how to enable DoH in each browser and what the settings actually do (What Is DNS over HTTPS?).

What about a VPN?

If you run a VPN, the cleanest answer is the VPN's own DNS. Queries stay inside the tunnel, the provider's resolver is the only observer, and neither DoH nor DoT is strictly required. When a VPN does not offer encrypted DNS, DoT on the device is the better default because it is system-wide, and DoH is the fallback when the network filters port 853.

Be careful with the combination. A browser with its own DoH setting can bypass the VPN's DNS path just as easily as it bypasses the operating system setting, which is why leak tests exist in the first place. The DNS leak guide covers the interaction in detail.

What enterprises filter on

Enterprises usually prefer DoT for the opposite reason. It is filterable: one port, one protocol, and policy can allow only the internal resolver. DoH breaks that model because browsers tunnel DNS to outside resolvers over port 443, bypassing internal filtering entirely, which is why several enterprise browsers ship with DoH disabled by default.

If you administer a fleet, treat per-browser DoH as a policy setting, not a convenience, and keep DoT on the infrastructure side. In our experience, the strongest setup for a managed network is DoT to an internal resolver with DoH locked down by policy.

The Leak Caveat: DoH and DoT Still Leak at the Browser Level

Encrypted DNS fixes the transport, not the leaks. A DNS leak is a lookup that escapes the protected path entirely, and no encryption on one layer stops it. The 2016 study of 283 Android VPN apps found that 84% leaked DNS requests even while the VPN was active (IMC 2016, Ikram et al.). Neither DoH nor DoT changes that class of failure on its own.

Three places this bites today:

1. A browser with its own DoH client ignores your operating system resolver, so system-level DoT is bypassed in practice.
2. Browser-level features resolve names outside the normal path altogether: WebKit's dns-prefetch on iOS and macOS leaked queries even through iCloud Private Relay in the August 2026 disclosure (Mysk's disclosure, 2026).
3. WebRTC answers STUN requests with your real IP outside any tunnel, a different leak with a different test (WebRTC Leak Test).

The DNS leak guide ties these together: how to test for each vector, what clean results look like, and what the WebKit findings mean for proxy users. The short version is that encrypted DNS moves the observer instead of removing it. Even a perfectly configured DoH client reveals each query to your chosen resolver, because encryption is not anonymity.

DoH also concentrates trust. Wikipedia's DNS leak entry defines the failure mode precisely, and the durable fix is the same for both protocols: run the encrypted transport through the VPN tunnel, not beside it, and re-test after every operating system update (Wikipedia: DNS leak). Oblivious DNS tries to fix the resolver-sees-everything problem by splitting the query across two servers, but it does nothing for the leak vectors above. ToolSura's IP address lookup gives you the public IP baseline to compare against before you start.

A practical rule: after you settle the DNS over HTTPS vs DNS over TLS choice, run a DNS leak test with the new resolver active and compare the results to a baseline. If your ISP's resolver appears in the list, the encrypted transport was never in the path. That test, plus a separate WebRTC check, takes ten minutes and closes the loop the comparison opens.

Related Tools & Further Reading

The three guides below cover the cluster around this comparison. The first is the hub for everything on DNS leaks; the other two cover the neighboring protocols in this conversation.

• DNS Leak Test Guide: the hub post, covering what counts as a leak, how to test, and the 2026 WebKit findings that encrypted DNS cannot fix alone.
• What Is DNS over HTTPS?: a deeper look at DoH, RFC 8484, and step-by-step enabling in Chrome, Firefox, Edge, Windows, and Android.
• WebRTC Leak Test: DNS is not the only way your identity escapes, and WebRTC leaks your real IP through STUN even when your DNS is clean.