DNS over HTTPS vs DNS over TLS: Encrypted DNS Explained

DNS over HTTPS vs DNS over TLS is the choice between two ways to encrypt one thing: your DNS lookups. Your device makes those lookups every time you open a website. Both hide those lookups from anyone watching the network. They differ in how they wrap the traffic and how visible they stay.

Traditional DNS travels in plaintext over port 53. Anyone on the path can read every domain you request, and some networks quietly rewrite the answers. Encrypted DNS closes that gap. The two mainstream standards, DoH and DoT, take different architectural routes to get there.

This guide explains how each protocol works and where they differ on privacy and control. It also shows how to turn encrypted DNS on across your browser and operating system.

What is encrypted DNS?

Encrypted DNS is any method that protects DNS queries with encryption so third parties cannot read or alter them. The two standard approaches are DNS over HTTPS and DNS over TLS. Both encrypt the channel between your device and the resolver, replacing the plaintext lookups that DNS has used since 1983.

Think of it as a postcard versus a sealed envelope. Plaintext DNS is the postcard that every handler can read; encrypted DNS seals it.

To understand why this matters, it helps to know what a normal lookup exposes. When you visit a site, your device asks a resolver for its IP address. If you need a refresher on that process, see our guide on how DNS works. That request has always been readable. Your ISP, a public Wi-Fi operator, or anyone with a network tap can log every domain you visit.

Plaintext DNS also invites tampering. A network in the middle can inject false answers to redirect you, block sites, or serve a captive portal. Encryption solves both problems at once: it stops eavesdropping and it prevents silent manipulation of the answers you receive.

How DNS over HTTPS (DoH) works

DNS over HTTPS sends DNS queries as ordinary HTTPS requests over port 443. RFC 8484 standardized DoH in 2018. Each lookup uses the same HTTP/2 or HTTP/3 framing your browser uses for websites. To a network observer, a DoH query looks identical to loading a page.

That camouflage is the defining trait of DoH. The traffic blends into all other HTTPS on port 443. That makes it hard to single out and block without breaking web browsing entirely. Many DoH resolvers expose a simple JSON API, which is the same interface several of our own tools rely on:

curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

The privacy win comes with a trade-off that matters inside organizations. A browser routing DoH straight to Cloudflare or Google can bypass the internal resolver an IT team uses for filtering. That is why network administrators often treat browser DoH with caution, even though end users tend to welcome it. The same bypass happens at home: a browser defaulting to DoH routes straight past Pi-hole or a router’s built-in parental controls, since those lookups never reach the local resolver. See our guide on why DNS-over-HTTPS breaks Pi-hole and parental controls for how to fix it.

How DNS over TLS (DoT) works

DNS over TLS wraps standard DNS messages in a TLS connection on dedicated TCP port 853. RFC 7858 defined DoT in 2016. It keeps the stack simple: DNS over TLS over TCP, with no HTTP layer added. The client opens a TLS session on port 853, then exchanges normal DNS wire-format messages inside it.

The dedicated port is what sets DoT apart. Encrypted DNS traffic stays identifiable on the wire. A network operator can monitor, log, or route it without losing sight of DNS activity. That visibility is an advantage in enterprise settings and a drawback for anyone trying to hide lookups from the network.

RFC 8310 defines two DoT privacy profiles. In strict privacy, the client configures a resolver name and refuses to connect unless it can verify the server’s certificate. In opportunistic privacy, the client tries to encrypt but proceeds without verification if it cannot. This protects against passive snooping only. DoT also powers Android’s Private DNS feature, available since Android 9. On Android 11 and later, that same setting transparently upgrades to DoH3 for supported resolvers such as Google and Cloudflare.

DNS over HTTPS vs DNS over TLS: the key differences

The core difference between DNS over HTTPS and DNS over TLS is visibility, not encryption. DoH hides on port 443 with web traffic, while DoT sits on dedicated port 853 where it stays recognizable. Everything else follows from that single design choice.

Notice that the encryption row is missing, because it does not differ. Both protocols use TLS, typically TLS 1.3, to secure the channel. Arguments that one is more secure than the other usually miss this point. Each is better suited to a particular goal, not cryptographically stronger.

Which is better, DoH or DoT?

Neither protocol is universally better. DoH is the stronger choice for personal privacy, because it resists blocking and hides which resolver you use. DoT is the stronger choice for network operators, because its dedicated port keeps DNS visible for security policy and troubleshooting.

The debate is really about whose interest wins. A privacy-focused user wants their lookups invisible even to the network they are on, which is exactly what DoH delivers. A security team wants the opposite: DNS it can inspect for malware callbacks and data exfiltration. DoT gives them that without dropping back to plaintext.

What encrypted DNS does not do

Encrypted DNS protects your lookups and nothing else. It does not hide your IP address from the sites you visit. It does not encrypt the rest of your traffic, and it does not make you anonymous. Treating DoH or DoT as a privacy cure-all is the most common mistake people make.

Two leaks survive encrypted DNS. First, once your device knows a site’s IP, it connects to that address in the open. The network still sees where you are going. Second, the Server Name Indication field in the TLS handshake often reveals the domain anyway. Encrypted Client Hello (ECH) closes the SNI gap, though broad support is still uneven. ECH also depends on DoH, which fetches its encryption keys over an encrypted lookup. That makes DoH a prerequisite for this next layer of privacy.

This is also why encrypted DNS is not a substitute for a VPN. A VPN tunnels all your traffic and changes your apparent IP for everything, while encrypted DNS covers a single step. The two pair well: if you want to understand where each fits, compare a VPN, a proxy, and Tor. A related failure mode is a DNS leak, where your lookups escape the encrypted path entirely.

How to enable encrypted DNS

Most people enable encrypted DNS in their browser or operating system with a single setting. Firefox turns DoH on by default in some regions, while Chromium browsers and Windows offer a toggle. The table below shows where each option lives and which protocol it uses.

After enabling it, confirm the change actually took effect. Browser settings can be overridden by an operating-system resolver, and vice versa. Test that lookups resolve as expected with a DNS lookup. Then compare response times against your old resolver using our DNS speed test.

What comes next: DoH3, DoQ, and Oblivious DoH

Several newer protocols build on encrypted DNS. DNS over QUIC (DoQ) and DNS over HTTP/3 (DoH3) improve speed, while Oblivious DoH (ODoH) improves anonymity. All are standardized or shipping, though mainstream browser support still trails the two established options.

DNS over QUIC arrived in RFC 9250 in 2022. It is essentially DoT moved onto the QUIC transport instead of TCP with TLS. It keeps the same trust model while cutting handshake latency and avoiding head-of-line blocking. A handful of resolvers, including AdGuard, support it today, but browsers have not broadly followed.

A close cousin is DNS over HTTP/3, or DoH3. It carries DoH over HTTP/3, so it keeps the port 443 camouflage while gaining QUIC’s speed. Mobile platforms are adopting it first, with Android using DoH3 since version 11.

Oblivious DoH arrived as experimental RFC 9230 in 2022. It tackles a problem the others ignore: the resolver itself can still see your IP alongside your query. ODoH inserts a proxy between client and target. No single party links your identity to your lookups unless the two servers collude. It is the same separation principle behind Apple’s iCloud Private Relay, which uses ODoH for name resolution.

Frequently asked questions

Related tools