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

DNS over HTTPS (DoH) and DNS over TLS (DoT) both encrypt your DNS lookups so your internet provider, a public Wi-Fi network, or anyone else on the wire can't read which sites you're resolving in plain text. The short answer: DoH tunnels DNS inside ordinary HTTPS traffic on port 443, which makes it hard to block or distinguish from normal web browsing, while DoT wraps DNS in its own dedicated TLS connection on port 853, which is easier for network administrators to identify and manage. Most consumer browsers default to DoH; most enterprise networks and mobile operating systems lean on DoT. Below is what each protocol actually does, where it's supported, and how to turn it on.

What is DNS over HTTPS (DoH)?

According to Cloudflare's own documentation, DNS over HTTPS "encrypts DNS queries by wrapping them inside regular HTTPS requests," which prevents attackers from forging or altering DNS traffic in transit. DoH sends DNS traffic over port 443, the same port used for all other HTTPS web traffic, and supports HTTP, HTTP/2 and HTTP/3. Because DoH queries ride the same port and protocol as normal web browsing, Cloudflare notes they are "difficult to distinguish from other HTTPS traffic on the network."

DoH is formally specified in IETF RFC 8484, which defines how a DNS query and response are encoded as the body of an HTTPS GET or POST request using the application/dns-message media type.

What is DNS over TLS (DoT)?

DNS over TLS takes a different approach. Per Cloudflare's documentation, "by default, DNS is sent over a plaintext connection," and DoT is "one way to send DNS queries over an encrypted connection" by wrapping standard DNS traffic inside a TLS-encrypted TCP connection. Cloudflare supports DoT on its 1.1.1.1 and 1.0.0.1 resolvers (and their IPv6 equivalents) specifically on port 853, and is compliant with RFC 7858.

The handshake, as Cloudflare describes it, works like this: the DNS stub resolver on your device stores a fingerprint (an SPKI pin) of the resolver's TLS certificate, opens a TCP connection to the resolver on port 853, performs a TLS handshake during which the server presents its certificate, and only then sends DNS queries over that now-encrypted channel. Every query after that point travels inside the same persistent, dedicated TLS/TCP connection.

Port and protocol: the core difference

What the standards actually define

Both protocols are formal IETF standards, not vendor inventions, which is part of why browser makers, mobile OS vendors and public resolvers were able to adopt them independently and still interoperate. RFC 7858's abstract describes DoT's purpose plainly: "encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network," and the spec is scoped specifically to "stub-to-recursive traffic" — in plain terms, the hop between your device and your chosen resolver, not the resolver's own lookups further upstream to authoritative servers.

RFC 7858 also defines two usage profiles for DoT: a Strict Privacy Profile, where the client refuses to fall back to unencrypted DNS if a TLS connection can't be established, and an Opportunistic Privacy Profile, where the client tries DoT but silently drops back to plaintext DNS if the encrypted connection fails — the RFC compares this to SMTP's opportunistic encryption model. That fallback behavior matters in practice: a client running in opportunistic mode can be downgraded to plaintext by a network that simply blocks port 853, without any visible warning to the user. RFC 8484, for its part, is a shorter, narrower spec: it defines how a single DNS query-response pair maps onto one HTTP exchange, which is also why DoH can piggyback on ordinary HTTP/2 and HTTP/3 connection handling instead of needing its own connection-management logic.

How Google Public DNS implements both

Google's own documentation confirms it has supported DoH (which it launched in 2016, originally just calling it "DNS-over-HTTPS") and DoT (added in 2019 "used by the Android Private DNS feature") for years, and that both "complement DNSSEC validation for end-to-end authenticated DNS resolution for DNSSEC-signed domains." Google restricts both protocols to TLS 1.2 and 1.3 only, with forward-secure, AEAD cipher suites — no older TLS or SSL versions are accepted.

Google's endpoints: DoT is reached at dns.google on port 853; DoH has two separate APIs, https://dns.google/dns-query (implementing RFC 8484, supporting both GET and POST) and https://dns.google/resolve (a simpler JSON API, GET only). Google's docs specifically warn not to confuse the human-readable https://dns.google/query? web page with either real API endpoint.

Which one is more private?

Both protocols encrypt the exact same payload — the DNS query name and type, and the resolver's answer — so neither is "more encrypted" than the other in terms of content. The privacy difference is about visibility of the transport itself. Because DoT runs on its own port, a network operator can see that DoT is happening (even if they can't read what's inside it) and choose to allow, block, or redirect it. Because DoH shares port 443 with ordinary web traffic, it's much harder for a network to selectively block DNS resolution without also disrupting general HTTPS browsing — which is exactly why some privacy-focused browsers and apps favor it by default, and why some enterprise network teams are wary of it: it can bypass network-level DNS filtering and logging policies that are built around seeing DNS traffic separately.

Where each is actually used

In practice, the two protocols aren't really competing for the same job:

• Browsers (Firefox, Chrome, Edge) implement DoH at the application level, letting the browser encrypt its own DNS lookups independently of whatever the operating system is doing.
• Android implements system-wide encrypted DNS through its Private DNS setting, which uses DoT — Google's support documentation confirms this is on by default on networks that support it, with "Automatic" and "Private DNS provider hostname" options.
• Windows Server ships a DoH client that administrators can configure via Group Policy or PowerShell, with three modes: DoH-only, "encrypted preferred, unencrypted allowed" (falls back silently if the server doesn't support DoH), or unencrypted-only.

So the realistic choice most people face isn't "DoH or DoT" in the abstract — it's whichever option your browser or OS actually exposes a toggle for. If you want encrypted DNS platform-wide on a phone, DoT via Android's Private DNS is the one you'll configure. If you just want your browser's own lookups encrypted independent of the OS, DoH is what Firefox, Chrome and Edge give you.

DoH and DoT don't replace DNSSEC

It's easy to conflate encrypted DNS transport with DNS authentication, but they solve different problems. DNSSEC cryptographically signs DNS records so a resolver can verify a response hasn't been tampered with by the time it leaves the authoritative server; DoH and DoT encrypt the pipe between your device and your resolver so nobody in between can read or alter the query in transit. Google's documentation is explicit that DoH and DoT "complement DNSSEC validation for end-to-end authenticated DNS resolution for DNSSEC-signed domains" — meaning you ideally want both: DNSSEC for integrity of the answer, and DoH or DoT for confidentiality of the question and answer as they travel between you and the resolver. Using encrypted DNS without DNSSEC still protects against eavesdropping, but it relies entirely on you trusting the resolver itself not to lie to you, since there's no cryptographic signature on the DNS record to check.

Why some networks restrict DoH specifically

The same property that makes DoH attractive to privacy-conscious users — that it's indistinguishable from regular HTTPS traffic — is exactly what makes some school, corporate and government networks uneasy about it. A network relying on DNS-based content filtering or malware-domain blocking to protect users can usually still see and filter DoT (because of its distinct port 853) without touching general web traffic, but blocking DoH specifically, without also degrading unrelated HTTPS browsing, typically requires either blocking known public DoH resolver IP addresses/hostnames outright or inspecting TLS handshake metadata to spot DoH connections — not simply blocking a port. This is the practical reason IT administrators often have stronger opinions about DoH than about DoT: DoT can be allow-listed or blocked cleanly at the network boundary, while DoH requires more active, ongoing effort to control.

Does either one slow down browsing?

Google's documentation notes a performance angle specific to DoH: because it rides over HTTP/2 and HTTP/3 (which itself runs over QUIC), DoH can benefit from connection reuse and QUIC's reduced handshake overhead in ways that plain DoT's TLS-over-TCP setup doesn't automatically get. Neither Cloudflare nor Google publishes a definitive "DoH is X% faster than DoT" figure in their documentation, so the practical performance difference depends heavily on your specific resolver, network path and client implementation rather than the protocol choice itself.

How to turn on DoH or DoT

Enabling either is a matter of using whatever official toggle your device or browser already ships:

• Android (DoT): Settings > Network & internet > Private DNS, then choose "Automatic" or enter a specific provider hostname (full steps in Google's Private DNS support page, linked above).
• Windows (DoH): configured per-DNS-server through Settings, PowerShell's Set-DNSClientServerAddress, or (on Windows Server) Group Policy, as documented in Microsoft's DoH client documentation, linked above.
• Cloudflare 1.1.1.1 (either): Cloudflare's own setup guides cover configuring DoH in a browser and connecting DoT clients directly to one.one.one.one on port 853 (linked above).
• Google Public DNS (either): point a DoH-capable client at dns.google/dns-query, or a DoT-capable client at dns.google:853, per Google's secure transports documentation, linked above.

If you've already set up a passkey instead of a password and compared a VPN against Tor for browsing privacy, encrypted DNS is the next layer worth closing: a VPN or Tor hides your traffic's destination from your ISP, but without DoH or DoT, your device's raw DNS lookups can still leak which sites you're about to visit before that tunnel even starts, unless the VPN or Tor client routes DNS through its own encrypted resolver.

What to do next

If your phone is Android, open Private DNS under network settings and confirm it isn't set to "Off." If you use Firefox, Chrome or Edge, check the browser's own DNS/privacy settings for a Secure DNS or DoH toggle — most have shipped it on by default for years. If you manage a network and need visibility into DNS traffic for security monitoring, DoT's dedicated port 853 is easier to allow-list and log than DoH's traffic, which is indistinguishable from general HTTPS browsing unless you specifically fingerprint DoH resolver endpoints. Either protocol is a meaningful upgrade over unencrypted DNS; which one you end up using will mostly be decided by what your OS or browser defaults to rather than a manual choice between the two.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage