DNS over HTTPS vs DNS over TLS: Encrypted DNS Compared

For decades DNS ran in the clear. Every domain you looked up was visible to your ISP, to anyone on the same Wi-Fi, and to anyone sitting on the path between you and your resolver. Even with HTTPS encrypting the page, the lookup that told the network you were visiting a given domain stayed readable. Two protocols now close that gap: DNS over TLS and DNS over HTTPS. They aim at the same problem and make a different tradeoff about who gets to see your DNS traffic.

Both encrypt the query so it cannot be read or altered on the wire. The difference is how visible the encrypted DNS itself is to the network it crosses, and that single difference explains almost every argument about which one to use.

What each one actually is

DNS over TLS (DoT), defined in RFC 7858, takes the normal DNS query and wraps it in a TLS session, the same encryption HTTPS uses. It runs on its own dedicated port, TCP 853. Because it lives on a known port, a network operator can see at a glance that DoT is in use and decide to permit it, block it, or force it through a chosen resolver. The traffic is encrypted, but its presence is obvious.

DNS over HTTPS (DoH), defined in RFC 8484, packages DNS queries as HTTPS requests and sends them over TCP 443, the same port all web traffic uses. To anyone watching the network, a DoH query is hard to tell apart from an ordinary page load. This makes DoH resistant to network filtering, which is a feature to a privacy-focused user and a problem to a security team that relies on seeing DNS.

Side by side

Property	DNS over TLS (DoT)	DNS over HTTPS (DoH)
Default port	TCP 853	TCP 443
Visible to the network	Yes, on a distinct port	No, blends with web traffic
Easy to block or redirect	Yes	Difficult
Typical enforcement point	Operating system resolver	Often the browser or app
Enterprise stance	Generally manageable	Often controlled or blocked
Encrypts the query	Yes	Yes
Authenticates the data	No, not by itself	No, not by itself

The last row is the one people conflate. Encryption stops eavesdropping and tampering in transit. It does not prove the answer came from the real zone owner. That authenticity guarantee comes from DNSSEC, a separate mechanism covered in DNSSEC Explained. Encrypted transport and signed records solve different halves of the DNS trust problem, and a complete setup wants both.

A useful way to hold the distinction: encrypted transport protects the query on its way to the resolver, while DNSSEC protects the answer's authenticity regardless of the path. If your resolver is honest but the network is hostile, encrypted transport is what you want. If the network is fine but you worry the answer was forged somewhere upstream, DNSSEC validation is what catches it. Real deployments face both risks at once, which is why the two are complementary rather than competing.

There is also a practical difference in where each protocol is configured. DoT is usually set at the operating system level, so every application on the device inherits it. DoH is frequently baked into individual applications, most visibly web browsers, which can enable it on their own without the operating system knowing. That application-level control is exactly what makes DoH powerful for a privacy-minded user and awkward for an administrator, because a single browser setting can change a device's DNS behavior without touching the system configuration.

The privacy tradeoff nobody mentions

Encrypted DNS hides your lookups from the network. It does not hide them from the resolver you send them to. In fact it does the opposite. When you switch to a public DoH or DoT provider, you move the complete record of every domain you visit from your ISP to that provider. You have not removed the observer. You have chosen a new one.

That choice can be an improvement, if you trust the new resolver's logging and retention more than your ISP's, or if your ISP is hostile or your network is untrusted. It can also be a lateral move dressed up as a win. The honest framing is that encrypted DNS relocates trust from the network path to the resolver operator, and the resolver operator sees everything.

Why enterprises push back on DoH

Corporate networks lean heavily on DNS as a control point. Internal DNS resolvers do several jobs at once:

• Filtering. Blocking known malicious domains, phishing, and command-and-control infrastructure at the DNS layer.
• Monitoring. DNS logs are a rich, cheap signal for detecting compromised hosts calling out. See DNS Tunneling Explained for why that visibility matters.
• Split-horizon resolution. Returning internal addresses for internal names, which only works if devices use the internal resolver.

DoH threatens all three at once. A browser or application configured to use an external DoH resolver quietly steps around the internal resolver. Its queries leave over port 443 looking like web traffic, so the usual DNS controls never see them. Malware authors noticed the same property and use DoH to hide their command-and-control lookups from network monitoring.

This is why enterprise guidance, including NIST deployment guidance, tends to insist that encrypted DNS point at the organization's own resolver rather than a random public one. The goal is to keep the encryption while keeping the enterprise resolver in the loop, so filtering and monitoring survive. Some organizations block external DoH endpoints outright and run their own DoH or DoT service internally.

The tension is real and worth stating plainly rather than pretending one side is simply right. A privacy advocate sees DoH keeping the network operator from logging every domain a person visits, which is a genuine protection on hostile or commercial networks. A defender sees the same property blinding the controls that catch a compromised laptop phoning home. Both are describing the same feature. The resolution most organizations reach is to provide the encryption themselves, so employees get a private channel and the security team keeps the visibility it needs to protect the fleet.

Which should you use

The right answer depends on who you are and what you are protecting against.

• On a personal device on untrusted networks, encrypted DNS to a resolver you trust is a clear gain. It stops the coffee-shop network and your ISP from logging your lookups. DoH is often easiest because it is built into browsers. Pair it with the rest of a hardening routine in Phone Privacy Hardening.
• On a managed corporate device, follow the organization's policy. The security team's DNS visibility is protecting you too, and bypassing it with personal DoH can blind the very controls that catch a compromise.
• As a network or resolver operator, prefer DoT where you want manageability, since its dedicated port makes policy simple. Offer DoH from your own infrastructure so users get encryption without escaping your controls.

How to secure it

1. Point encrypted DNS at a resolver you actually trust. The resolver sees all your lookups. Choose one with a clear, minimal logging policy, and prefer your own or your organization's over an unknown public one.
2. Do not treat encryption as authentication. Add DNSSEC validation so answers are verified as genuine, since neither DoH nor DoT proves the data is real.
3. In an enterprise, control the DoH endpoint. Steer devices to an internal encrypted resolver and block unmanaged external DoH so filtering and monitoring keep working.
4. Watch for DoH used as an evasion channel. Malware uses DoH to hide command-and-control. Keep visibility by forcing internal resolution and monitoring for connections to known public DoH endpoints.
5. Layer it with the rest. Encrypted DNS is one control. Combine it with DNSSEC, HTTPS, and spoofing defenses for a complete picture. See DNS Spoofing Explained.

What happens on a single encrypted lookup

Following one query from click to answer shows where each protocol spends its effort. Suppose you type a domain into a browser configured for DoH.

The browser first needs a connection to the DoH resolver. It opens a TLS session to the resolver's address on port 443, completing the standard TLS handshake that authenticates the resolver by its certificate and negotiates session keys. On a reused connection this cost is already paid, which matters because DoH keeps a persistent HTTPS connection open and sends many lookups down it.

The browser then formats the DNS question as an HTTPS request. The domain you are resolving rides inside the encrypted request body, so anyone watching the wire sees a TLS record to port 443 and nothing about which name you asked for. This is the property that makes DoH blend with ordinary web traffic, because at the packet level it is ordinary web traffic to a web server that happens to answer DNS questions.

The resolver receives the question, performs the actual resolution on your behalf, walking the DNS hierarchy or answering from its cache, and returns the answer inside the encrypted HTTPS response. The browser reads the address and proceeds to connect to the site. Every hop on the network between you and the resolver saw encrypted bytes and learned nothing about the name.

Now run the same lookup under DoT. The difference appears at the very first step. Instead of port 443, the operating system opens a TLS session to the resolver on port 853, the dedicated DoT port. The query is wrapped in TLS the same way, so the content is equally protected. The distinction is entirely one of visibility. A network operator watching connections sees traffic to port 853 and knows, without reading anything, that DoT is in use. Under DoH that same operator would have seen only another HTTPS connection. The encryption strength is the same in both walkthroughs. What differs is whether the network can tell that DNS is happening at all.

Detection and management signals

For a network operator, the two protocols present very different handling problems, and the signals that reveal them are worth knowing.

• A distinct destination port. DoT announces itself by using TCP 853. Any flow to that port is DoT, which makes allowing, blocking, or redirecting it a one-line policy. This is the simplest signal in the entire discussion.
• Connections to known public DoH endpoints. DoH hides at the protocol level, but the resolvers that offer it live at known addresses. Maintaining a list of public DoH endpoint addresses and watching for connections to them is the common way networks regain some visibility over DoH use.
• Canary domains. Some browsers check a special domain before enabling DoH automatically, and a network that answers that check in a particular way can signal the browser to stand down. This gives an operator a cooperative off switch for browser-driven DoH.
• Loss of internal resolver traffic. A device that suddenly stops querying the internal resolver, while still reaching the internet, is a sign that an application has quietly switched to its own encrypted resolver. The absence of expected DNS is itself the signal.
• TLS fingerprinting on port 853. Because DoT sits on a known port, its TLS characteristics are easy to profile, which helps distinguish a sanctioned internal DoT resolver from an unexpected external one.

The through-line is that DoT is trivial to see and manage while DoH forces defenders to work indirectly through endpoint lists and behavioral gaps. That asymmetry is the practical reason enterprises treat the two so differently.

Common misconceptions

"Encrypted DNS makes me anonymous." It hides your lookups from the network path. The resolver you chose still sees every domain you resolve, tied to your IP address. Anonymity would require hiding your queries from the resolver too, which encrypted transport does not attempt.

"DoH is simply more secure than DoT." The two use the same TLS encryption and offer the same protection of the query in transit. DoH is harder for a network to block, which is a privacy advantage on a hostile network and a monitoring problem on a corporate one. Neither is universally more secure. They make a different tradeoff about visibility.

"Encrypted DNS means the answers are verified." Encryption protects the query and answer in transit. It does not prove the answer came from the real zone owner. That authenticity guarantee is DNSSEC, a separate mechanism. A resolver could return a forged answer over a perfectly encrypted channel.

"Turning on DoH in my browser protects my whole device." A browser's DoH setting changes only that browser's DNS. Other applications on the device keep using the system resolver unless they are configured separately. DoT set at the operating system level is what covers every application at once.

"Blocking port 853 stops encrypted DNS." It stops DoT, whose traffic uses that port. DoH continues over port 443 alongside all other web traffic and is unaffected. This is exactly why DoH is the harder of the two to control.

How it developed

Both protocols emerged from the same recognition that DNS running in plain text was a privacy and integrity gap the rest of the web had largely closed with HTTPS. DoT was specified first, in RFC 7858, taking the direct approach of wrapping DNS in TLS on a dedicated port. It fit naturally into operating-system resolvers and into the way network operators already think about ports and policy.

DoH followed in RFC 8484 with a different design goal in mind. By packaging DNS as HTTPS and sending it over port 443, DoH aimed to make encrypted DNS resistant to the network-level blocking that a dedicated port invites. Browser vendors adopted it quickly because it let them offer users encrypted DNS without depending on the operating system or the local network to cooperate. That application-level control is what turned DoH into a point of tension, because a single browser update could change a device's DNS behavior in ways administrators had not planned for.

The response from the enterprise and standards community was to focus less on blocking encryption and more on steering it. Guidance converged on the idea that organizations should run their own encrypted resolvers, offer DoH or DoT from infrastructure they control, and use canary domains and endpoint controls to keep unmanaged external resolvers from quietly taking over. The debate is less about whether DNS should be encrypted, which is largely settled, and more about who operates the resolver that now sees every lookup.

Performance and reliability considerations

Beyond privacy and visibility, the two protocols carry practical differences that affect how they behave day to day.

Both add a setup cost that plain DNS avoids, because a TLS session has to be established before the first query. That cost is paid once per connection and then amortized across many lookups, since both DoT and DoH keep the connection open and reuse it. On a fresh connection the extra round trips are noticeable, and on a warm one the overhead is small. Connection reuse is the reason encrypted DNS feels fast in ordinary browsing even though the first lookup after idle is slower.

Reliability follows from where each protocol is configured. DoT set at the operating system level gives the whole device one consistent resolver, which is simple to reason about and simple to fail over. DoH configured inside individual applications can produce a device where the browser uses one resolver and the rest of the system uses another, so a resolution problem can appear in one application and not others. That split can be confusing to diagnose, because the device is using two different DNS paths at once.

Fallback behavior deserves attention too. Some clients will fall back to plain DNS if the encrypted resolver is unreachable, which quietly undoes the privacy you configured. A client that fails closed refuses to resolve rather than leak the query in plain text, which is the safer behavior for privacy but can look like a broken connection. Knowing which mode your client uses tells you what happens on the day the encrypted resolver has a problem.

Frequently asked questions

Which is better for privacy, DoH or DoT? On a hostile or untrusted network, DoH is harder for that network to block or observe, so it gives a privacy-minded user more resistance to interference. Both encrypt the query equally well. The privacy that matters most is your choice of resolver, because whichever protocol you pick, the resolver sees all your lookups. Choose one with a clear, minimal logging policy.

Does encrypted DNS replace a VPN? No. Encrypted DNS protects only your DNS lookups. A VPN encrypts and tunnels much more of your traffic and changes the IP address the destination sees. They protect different things, and encrypted DNS is a much narrower tool. On an untrusted network encrypted DNS is a useful layer, and a VPN addresses a broader set of concerns.

Should I use encrypted DNS on my work laptop? Follow your organization's policy. Corporate networks often rely on seeing DNS to filter malicious domains and detect compromised machines. Turning on personal DoH can bypass those protections, which are defending you as well as the fleet. If the organization offers an internal encrypted resolver, use that.

Can encrypted DNS be blocked? DoT is easy to block because it uses the dedicated port 853, so an operator can simply deny that port. DoH is difficult to block because it looks like ordinary HTTPS on port 443, and blocking it would mean interfering with normal web traffic. Networks that want to control DoH usually do so by blocking known public DoH endpoint addresses rather than the protocol itself.

Is encrypted DNS enough on its own? It closes one gap, the readability of your lookups on the network path. It does not verify that answers are authentic, which is DNSSEC's job, and it does not protect the rest of your traffic. A complete setup pairs encrypted transport with DNSSEC validation and a resolver you trust. Treat it as one control among several.

Why do malware authors like DoH? The same property that helps a privacy-minded user helps an attacker. Command-and-control lookups sent over DoH blend into normal web traffic and slip past DNS-based monitoring that would otherwise flag them. This is why defenders watch for connections to known public DoH endpoints from machines that should be using the internal resolver.

Does the resolver I pick really matter that much? Yes, it is the central decision. Encrypted DNS moves the complete record of every domain you visit from your network to your resolver operator. If the operator logs and retains aggressively, you may have traded one observer for a worse one. Read the logging and retention policy before switching, and prefer your own or your organization's resolver where you can.

Encrypted DNS is a genuine improvement over sending your lookups in plain text to anyone who cares to read them. Just be clear-eyed about what it changes. It moves the observer rather than removing it, and the port it runs on decides whether your network can still do its job. Pick the transport that fits your threat model, choose the resolver deliberately, and add DNSSEC on top. For how attackers abuse DNS and forged infrastructure in live intrusions, see our exploit intelligence dashboard.

Related guides

• DNSSEC Explained
• DNS Spoofing Explained
• How HTTPS Works
• Phone Privacy Hardening