DoH vs DoT: What is the Difference Between DNS over HTTPS and DNS over TLS?

Every time you click a link or type an address into your browser, your device sends a lookup request to a recursive resolver. For decades, traditional DNS servers processed these requests over cleartext UDP and TCP on port 53. Because this traffic is completely unencrypted, anyone positioned along the communication route can inspect your browsing habits or manipulate the answers you receive.

To solve this persistent security gap, the Internet Engineering Task Force (IETF) standardized two distinct cryptographic transport protocols: DNS over TLS (DoT) and DNS over HTTPS (DoH). While both protocols encrypt domain requests between your client and a resolver, they operate at different layers of the networking stack and create very different outcomes for enterprise network control, user privacy, and threat management.

Why Encrypt DNS at All?

Cleartext DNS remains one of the largest structural vulnerabilities of the legacy internet architecture. When queries travel across public or untrusted connections without encryption, they expose users and organizations to three primary hazards:

1. Passive Eavesdropping: Any entity with visibility into network traffic—including internet service providers (ISPs), public Wi-Fi operators, and surveillance programs—can log every domain lookup your device performs. Even if the subsequent web traffic uses HTTPS, your DNS queries still advertise exactly which services, apps, and domains you interact with.

2. On-Path Tampering and Interception: Attackers sharing a local network can intercept cleartext requests and inject fabricated answers, a tactic known as a man-in-the-middle attack. This allows an adversary to reroute legitimate traffic toward malicious infrastructure without alerting the victim.

3. Redirection and Spoofing: In a typical DNS spoofing scenario, altered lookup responses guide users to phishing landing pages that mimic internal company portals, banking sites, or Single Sign-On providers.

Encrypting the transport channel between the client device (stub resolver) and the upstream recursive resolver closes these attack vectors. It guarantees that eavesdroppers see only encrypted streams rather than plain-text domain names, while verifying that the responses cannot be modified by middleboxes on the path.

What Is DNS over TLS (DoT)?

DNS over TLS, standardized by the IETF in RFC 7858, secures classic DNS wire format messages inside an encrypted Transport Layer Security (TLS) tunnel.

Instead of using the standard port 53, DoT operates over its own dedicated network port: port 853.

When a device initiates DoT, it establishes a reliable TCP connection to port 853 of a designated resolver, completes a standard TLS cryptographic handshake, and exchanges DNS queries within that secure session. RFC 7858 prohibits sending cleartext data over port 853; if the TLS negotiation fails, the connection terminates rather than falling back to unencrypted transmission on that port.

Because DoT adds no application-layer wrappers, it keeps query overhead minimal. Once the connection is established, clients can reuse existing TLS sessions and pipeline multiple queries simultaneously to prevent handshake latency on every lookup.

Operating System and Platform Support

• Android: Starting with Android 9 (Pie), Google added native DoT support via the “Private DNS” setting. When activated with a chosen hostname, all device-wide DNS queries route through DoT.
• Linux: System resolvers such as systemd-resolved and local caching daemons like Unbound or Stubby provide native DoT support.
• Enterprise Appliances: Modern next-generation firewalls (NGFW) and dedicated recursive resolvers frequently support DoT natively to encrypt internal queries headed out to protective upstream resolvers.

What Is DNS over HTTPS (DoH)?

DNS over HTTPS, standardized in RFC 8484, takes a different architectural route. Rather than introducing a dedicated transport channel for domain queries, DoH encapsulates DNS request and response messages inside standard HTTP/2 or HTTP/3 payloads encrypted with TLS.

DoH operates over port 443, the same network port utilized by standard web traffic.

Under RFC 8484, DNS queries are transmitted as HTTP GET or POST requests bearing the specific MIME type application/dns-message. Because these exchanges are fully multiplexed alongside web traffic on port 443, external network observers cannot easily distinguish a DNS lookup from an ordinary secure web page download.

This design gives end-user privacy maximum resilience. If an intermediate network or ISP attempts to inspect or filter DNS traffic, DoH prevents them from doing so unless they break and inspect all outbound HTTPS connections.

Operating System and Browser Support

• Web Browsers: Mozilla Firefox, Google Chrome, Microsoft Edge, and Brave all feature configurable DoH engines. Firefox pioneered default DoH rollout in multiple regions, while Chromium-based browsers support automatic upgrades to DoH when the underlying operating system uses a compatible resolver.
• Windows 11: Windows 11 includes built-in system-wide DoH support. Network administrators and users can assign DNS server IP addresses and designate manual DoH template URLs via network adapter properties.
• Apple (macOS and iOS): Apple platforms support DoH and DoT natively through encrypted DNS configuration profiles or dedicated network extension apps.

DoH vs DoT: Side-by-Side Comparison

Key Differences Explained

Port Allocation and Network Visibility

The clearest operational divergence between DoT and DoH centers on their assigned port numbers.

DoT operates on port 853. This dedicated assignment makes network monitoring predictable. A systems administrator can glance at firewall logs, verify whether port 853 traffic is flowing to an authorized internal resolver, and block rogue connections with a single rule. If an unmanaged endpoint attempts to contact an unauthorized resolver on port 853, the firewall drops the packet without disrupting normal web traffic.

DoH routes over port 443. Because port 443 carries virtually all encrypted internet activity, a network cannot block port 443 without severing access to the World Wide Web. As a result, network administrators cannot tell whether an outbound packet is an ordinary API call, a user loading an e-commerce website, or an encrypted DNS request directed to an external resolver.

Security vs. Privacy Trade-Off

DoH and DoT highlight an ongoing debate between end-user privacy and centralized network defense.

From an individual privacy standpoint, DoH excels. On public Wi-Fi networks or in regions where service providers log and monetize customer browsing history, DoH hides query metadata within regular web browsing streams, protecting users from invasive tracking.

From a corporate security perspective, unmanaged DoH introduces significant risk. Many modern threat prevention systems rely on DNS filtering to intercept known command-and-control (C2) domains, stop data exfiltration tunnels, and block phishing endpoints before TCP handshakes can even start.

When a browser or rogue application inside a corporate network switches to external DoH by default:

• It completely bypasses local DNS firewalls and Active Directory resolvers.
• It blinds security information and event management (SIEM) tools to endpoint query logs.
• Advanced threat actors can abuse DoH channels to communicate covertly with external command infrastructure, hiding malicious payloads inside ordinary port 443 sessions.

For this reason, corporate IT teams often block unauthorized DoH endpoints at the IP boundary or distribute group policies that mandate company-approved resolvers.

Performance and Latency

In everyday environments, both protocols provide rapid responses once their initial connections are active. However, their underlying mechanics create subtle performance differences.

DoT uses raw DNS payloads over TLS. This keeps framing compact, requiring fewer bytes per transaction. It relies on standard TCP keep-alive mechanisms and TLS session resumption to minimize connection overhead.

DoH incurs slightly more processing overhead because it must encapsulate DNS queries inside HTTP headers and maintain HTTP state machines. However, because DoH benefits from HTTP/2 and HTTP/3 multiplexing, it can handle hundreds of concurrent requests across a single stream without head-of-line blocking, while also utilizing HTTP caching mechanisms. For standard web browsing, the real-world latency difference between DoT and DoH is rarely noticeable to human users.

Which Should You Choose?

Selecting between DoT and DoH depends on your environment, operating requirements, and who controls the network infrastructure.

Individual Users on Untrusted or Public Networks

If you frequently travel, work from coffee shops, or rely on residential ISPs that monitor your queries, DoH is generally the more resilient option. Enabling DoH in your favorite browser ensures that local network operators cannot log the domains you visit or inject tracking scripts.

Enterprise and Corporate Networks

Organizations should prioritize DoT or strictly managed DoH.

Within corporate environments, visibility is non-negotiable. IT teams must ensure that all workstations, mobile devices, and IoT hardware resolve names through approved protective resolvers.

To maintain control while retaining encryption, enterprises should:

• Configure endpoints to use internal recursive resolvers via DoT.
• Enforce administrative policies in browsers like Chrome, Edge, and Firefox to prevent users or updates from toggling unmanaged public DoH resolvers.
• Block outbound traffic to known public DoH resolver IPs on firewalls to prevent internal security controls from being bypassed.
• Apply established DNS security best practices to guarantee uniform protection across all internal zones.

Mobile Devices

Mobile devices move constantly between trusted enterprise Wi-Fi, home routers, and cellular carrier towers. Android handles this seamlessly through its built-in Private DNS feature using DoT, providing uniform encryption across every app on the device without requiring separate software. iOS and macOS devices can achieve the same protection through configuration profiles supporting either DoT or DoH.

What About DNS over QUIC (DoQ)?

As transport architectures evolve, a newer protocol has entered the conversation: DNS over QUIC (DoQ), standardized in RFC 9250.

While DoT and legacy DoH run on TCP, DoQ runs on QUIC over UDP port 853. QUIC integrates TLS 1.3 encryption directly into its transport handshake. This structure solves head-of-line blocking, accelerates connection establishment through 0-RTT session resumption, and supports seamless connection migration when mobile devices jump between Wi-Fi and mobile data networks.

While DoQ represents the leading edge of encrypted DNS research and performance, production adoption remains in its early stages compared to the mature ecosystems of DoT and DoH.

DoH/DoT vs DNSSEC: Why You Need Both

A common misconception is that activating DoH or DoT makes other DNS security protocols redundant. In reality, encrypted transport and Domain Name System Security Extensions (DNSSEC) address two completely different parts of the security lifecycle.

• DoH and DoT protect the transport path: They encrypt the connection between your device and the recursive resolver. They prevent eavesdroppers on your local network or ISP from snooping on the query. However, they tell you nothing about whether the upstream resolver is providing an accurate answer from the genuine domain owner.
• DNSSEC protects data integrity: DNSSEC uses cryptographic digital signatures (RRSIG records) published in the zone file to verify that the DNS data returned has not been altered at the authoritative level or poisoned in resolver caches.

If an attacker compromises an upstream authoritative nameserver or executes a DNS cache poisoning attack, DoH and DoT will deliver that falsified answer directly to your device over a secure, encrypted tunnel.

To ensure complete infrastructure integrity, organizations must implement DNSSEC across their own domain zones while configuring resolvers to validate signatures. You can test whether your current domains publish valid cryptographic signatures by running them through our automated DNSSEC checker.

Frequently Asked Questions

Is DoH more secure than DoT?

Neither protocol is inherently more secure than the other from a purely cryptographic perspective. Both employ robust TLS encryption to shield DNS queries from observation and manipulation. The true difference lies in network visibility: DoH provides greater privacy against local network monitoring by sharing port 443 with web traffic, whereas DoT provides superior management capabilities for enterprise security teams by using dedicated port 853.

Should I turn DNS over HTTPS on or off?

For individual users on personal devices, keeping DoH enabled provides immediate privacy benefits by preventing local network operators and ISPs from logging lookups.

However, in corporate environments, unmanaged DoH should typically be disabled or redirected toward company-approved resolvers. When left unmanaged, browser-level DoH bypasses internal network firewalls, content filtering rules, and threat monitoring appliances.

Can DoH be blocked on a network?

Yes. Although DoH cannot be blocked by closing a specific port without also disabling HTTPS web traffic on port 443, organizations can restrict DoH using alternative controls. Network administrators can block access to the public IP addresses of known commercial DoH resolvers, restrict access via web proxies, or use next-generation firewalls with application identification (App-ID) engines capable of recognizing DoH traffic signatures.

Does a VPN replace the need for DoH or DoT?

A Virtual Private Network (VPN) encrypts all network traffic leaving your device, including your DNS queries, inside an encrypted tunnel back to the VPN gateway. If you trust your VPN provider and configure your system to resolve queries through their private recursive resolvers, you do not necessarily need DoH or DoT, as the entire tunnel is already encrypted.

However, running DoH or DoT inside or outside a VPN adds defense-in-depth, ensuring queries remain shielded even if split-tunneling leaks standard DNS packets.

Final Thoughts: Protect Your Resolvers and Your Records

Both DNS over HTTPS and DNS over TLS deliver valuable privacy improvements over the forty-year-old cleartext UDP port 53 standard. Choosing between them comes down to context: DoH gives individual users stealth and privacy on public networks, while DoT provides organizations with the clear boundaries and visibility needed to enforce enterprise security policies.

However, encrypting the way your team looks up third-party domains addresses only half of your infrastructure exposure. You must also defend the public DNS records that point the rest of the world to your company’s web services, applications, and email servers.

Unmonitored domain zones are exposed to unauthorized record modifications, missing cryptographic signatures, and expired certificates. PowerDMARC helps organizations maintain total domain oversight through DNS Security Monitoring and Compliance.

By pairing continuous record monitoring and DNS Timeline change alerts with our free DNSSEC checker, you can ensure your company’s DNS infrastructure remains auditable, compliant, and defended against spoofing from every angle.