DNS over HTTPS vs DNS over TLS: DoH vs DoT Compared

Quick Answer: DNS over HTTPS (DoH) encrypts DNS queries by routing them through port 443 alongside standard web traffic, making them indistinguishable from normal HTTPS requests. DNS over TLS (DoT) encrypts DNS queries through a dedicated TLS connection on port 853, keeping DNS traffic separate and transparent to network administrators. Both protocols protect against eavesdropping and DNS spoofing. DoH is easier for individual users; DoT gives enterprise networks better visibility and control.

The Domain Name System (DNS) translates domain names like whoisfreaks.com into IP addresses that computers use to route traffic. Every web request, email lookup, and API call passes through DNS before it reaches its destination.

Traditional DNS sends queries in plaintext over UDP port 53. Anyone with access to the network path between your device and the resolver can read exactly which domains you are querying, alter responses, or redirect traffic to a different IP address. This exposure affects every DNS query, including those on encrypted HTTPS websites, because the DNS lookup itself happens before the encrypted connection is established.

DNS over HTTPS (DoH) and DNS over TLS (DoT) solve this by encrypting DNS queries end to end. Both are IETF-standardized protocols: DoT is documented in RFC 7858 and DoH in RFC 8484. They differ significantly in how they route traffic, which ports they use, and how visible they are to network administrators. This article covers how each protocol works, their trade-offs on performance and privacy, and when each is the right choice.

DoH vs DoT: At a Glance

DoH (DNS over HTTPS) and DoT (DNS over TLS) are the two primary standards for encrypted DNS transport. The DNS over HTTPS vs TLS question comes up constantly in security and networking discussions because both protocols offer equivalent encryption but differ significantly in deployment. They serve the same core purpose: preventing third parties from reading or altering your DNS queries. But they take different architectural approaches. DoH wraps DNS traffic inside HTTP/2 or HTTP/3 requests on port 443, the same port used by all HTTPS traffic. DoT sends DNS queries directly over a TLS-encrypted TCP connection on port 853.

From a security standpoint, both provide equivalent protection. The decision between them depends on your deployment context: DoH is the right default for end-user devices and browsers; DoT is typically preferred in enterprise environments where DNS traffic needs to be monitored, filtered, or proxied at the network layer.

What Is DNS and How Does It Work?

DNS translates human-readable domain names (like whoisfreaks.com) into numeric IP addresses that computers use to communicate. When you type a URL, your browser checks its local cache first; if no record exists, it sends a request to a recursive resolver, which works through the DNS hierarchy until it finds the authoritative nameserver for that domain and returns the correct IP address. The lookup typically completes in under 100ms and the result is cached for repeat visits. You can inspect the live DNS records for any domain (including A, AAAA, MX, NS, TXT, SPF, SOA, and CNAME types) using the WhoisFreaks DNS lookup tool.

DNS Security Challenges and the Need for Encryption

DNS Caching and Its Risks

DNS caching speeds up browsing by storing resolved IP addresses locally so repeat lookups skip the full resolution chain. That performance benefit comes with two security trade-offs.

Cache Poisoning: Attackers can inject false DNS records into a resolver's cache, causing it to return wrong IP addresses for legitimate domains. Users get redirected to lookalike sites designed for phishing or malware delivery. DNS cache poisoning is one of the most persistent DNS attack vectors because a poisoned cache affects every user querying that resolver until the record expires.

Stale DNS Records: Cached records eventually fall out of sync with the authoritative server, particularly when a site moves to new hosting or takes a service offline. Users hitting a stale record land on a defunct or incorrect IP, which causes failures that are hard to diagnose.

Why DNS Encryption Is Important

DNS queries travel in plaintext by default, which creates several exposure points that encryption eliminates.

Eavesdropping: On any network you do not fully control, including public Wi-Fi, ISP infrastructure, or shared corporate networks, anyone monitoring traffic can read your DNS queries. Every domain you look up is visible, which reveals browsing patterns even when the sites themselves use HTTPS.

Man-in-the-Middle Attacks: Attackers positioned between your device and the DNS resolver can intercept and rewrite DNS responses, pointing your request to a server they control. The connection proceeds normally from your browser's perspective, but you are communicating with the wrong destination.

Privacy Exposure: DNS queries reveal more about user behavior than most people realize. A DNS log shows every domain a user contacts, including medical information sites, financial services, and private communications platforms. Encrypting this traffic protects users from surveillance, behavioral profiling, and targeted advertising based on DNS data.

DNS Lookup Vulnerabilities

Two specific attack patterns target the DNS lookup process directly.

Spoofed Responses: Without transport encryption, an attacker can send a forged DNS response before the legitimate resolver does. The client accepts the first answer it receives and establishes a connection to the attacker-controlled IP. DoH and DoT both prevent this by requiring that responses come through an authenticated, encrypted channel. For related DNS-based attack vectors, see the guide on defending against DNS flood attacks.

DNS Query Manipulation: Attackers can modify DNS queries in transit to alter which domain is being resolved, or suppress queries entirely to cause selective service outages. Encrypting queries with DoH or DoT removes the window of opportunity for this class of manipulation.

DNS Over HTTPS (DoH) vs DNS Over TLS (DoT): How Each Protocol Works

What Is DNS Over HTTPS (DoH)?

DNS over HTTPS encrypts DNS queries by sending them as standard HTTPS requests over port 443. From the network's perspective, DoH traffic looks identical to any other HTTPS session, because it is carried inside the same HTTP/2 or HTTP/3 framing used by web traffic.

When your browser makes a DoH request, it sends an HTTPS POST or GET to a DoH resolver endpoint (for example, https://1.1.1.1/dns-query for Cloudflare). The resolver responds with the DNS answer, also over HTTPS. The entire exchange is encrypted with TLS, authenticated with a certificate, and indistinguishable from a web request to a network observer.

Key properties of DoH:

• Privacy: DNS queries are embedded in HTTPS traffic, making them difficult to isolate or inspect at the network level.
• Censorship resistance: Because DoH uses port 443, blocking it would require blocking all HTTPS traffic, which is not practical.
• Performance: DoH can use HTTP/2 multiplexing to handle multiple DNS queries over a single connection, reducing latency under load.
• Browser integration: Chrome, Firefox, and Edge all support DoH natively. Users can enable it in browser privacy settings without any system-level configuration.

What Is DNS Over TLS (DoT)?

DNS over TLS encrypts the same DNS queries using TLS directly, without the HTTP layer. It operates on a dedicated TCP port: port 853. The DNS client establishes a TLS handshake with the resolver on that port, then sends DNS queries over the encrypted channel using standard DNS wire format.

DoT is defined in RFC 7858 and has been the standard for Android's "Private DNS" feature since Android 9. It is also widely supported by enterprise DNS resolvers, including those from Cloudflare, Google, and Quad9.

Key properties of DoT:

• Transparency: DoT traffic on port 853 is identifiable as DNS traffic. Network administrators can monitor, log, and apply security policies to it without losing visibility into DNS activity.
• Simplicity: DoT does not add HTTP framing on top of TLS. The protocol stack is DNS → TLS → TCP, which is simpler than DNS → HTTP/2 → TLS → TCP.
• Enterprise control: Because DoT uses a dedicated port, organizations can route all DoT traffic through their own internal resolvers using firewall rules, enforcing DNS security policies for the entire network.
• Two operating modes: DoT can run in strict mode (the client requires a valid certificate from a specific resolver and fails if the connection cannot be established) or opportunistic mode (the client attempts TLS but falls back to plaintext if the server does not support it). Strict mode is the secure default for any production deployment.

Comparison: DoH vs DoT Side by Side

DNS over QUIC (DoQ), defined in RFC 9250, uses QUIC's multiplexed UDP transport rather than TCP. Each DNS query runs in its own QUIC stream, which eliminates the head-of-line blocking that affects DoH and DoT when a packet is lost on a congested connection. DoQ is most relevant for mobile deployments and resolver infrastructure where high-latency or lossy networks make TCP-based protocols less reliable. As of 2026, resolver support is growing but broad client OS and browser adoption has not arrived, so DoQ is primarily a consideration for resolver operators rather than end users.

DoH, DoT, and DNSSEC: Understanding the Differences

DoH and DoT are often mentioned alongside DNSSEC, but they solve different problems and operate at different points in the DNS resolution chain.

DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records so resolvers can verify that the response came from the authoritative server and has not been tampered with. It protects the integrity of DNS data at the source. DNSSEC does not encrypt DNS traffic. A network observer can still read which domains are being queried. It answers the question: "Is this DNS record authentic?"

DoH and DoT encrypt the transport channel between the DNS client and the recursive resolver. They prevent eavesdropping and man-in-the-middle attacks on the last-mile connection between the end user's device and the resolver. They answer the question: "Can anyone intercept or alter my DNS query in transit?"

In a well-configured network, DNSSEC and either DoH or DoT work together: DNSSEC validates that the DNS data coming back from the authoritative nameserver is correct, while DoH or DoT ensures that data cannot be read or altered between the resolver and your device. Tracking historical changes to a domain's DNS records (nameserver delegations, A record pivots, MX changes over time) is separately useful for threat investigations and infrastructure audits. The WhoisFreaks historical DNS lookup surfaces that record history across A, AAAA, MX, NS, TXT, CNAME, and SOA types from a database of over 15 billion records.

DoH vs DoT Adoption and Performance in 2026

1. Adoption Trends and Industry Support

IETF Standards Status: DoT is defined in RFC 7858 (2016) and DoH in RFC 8484 (2018). Both are full Internet Standard track specifications. The DNS over QUIC (DoQ) variant is defined in RFC 9250 (2022) and is beginning to appear in resolver implementations, though broad browser and OS support remains limited as of 2026.

Browser and OS Support: Chrome, Firefox, and Edge integrate DoH natively. Windows 11 and macOS support both DoH and DoT at the OS level, though DoT on desktop operating systems still requires manual configuration in most setups. Android 9 and later expose DoT as "Private DNS" in network settings. Enabling it takes a single toggle and a resolver hostname.

DNS Providers: Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 all support both protocols. Cloudflare's DoH endpoint is https://1.1.1.1/dns-query; its DoT hostname is 1dot1dot1dot1.cloudflare-dns.com on port 853.

Enterprise Adoption: Organizations adopting encrypted DNS typically prefer DoT for internal infrastructure because it preserves the ability to monitor and filter DNS traffic through standard network tooling. DoH adoption in enterprise environments has been slower because it bypasses DNS filtering appliances unless those appliances support DoH interception directly.

2. Performance Considerations

DNS over HTTPS (DoH):

DoH uses HTTP/2 multiplexing, which lets the client send multiple DNS queries over a single persistent connection without waiting for each to resolve in sequence. Under high query volume, this reduces connection overhead significantly. The trade-off is latency on the first request: establishing an HTTPS session involves a TCP handshake, a TLS handshake, and HTTP negotiation before the first query can be sent. On subsequent queries to the same resolver, connection reuse largely eliminates this overhead. A SamKnows measurement study across nearly 300,000 tests found that Cloudflare averaged 23.4ms for standard DNS and 25.2ms for DoH, a 1.8ms difference within measurement noise. The larger variable in that dataset was choice of resolver, not the protocol itself.

DNS over TLS (DoT):

DoT establishes a TLS connection directly over TCP on port 853. Once the handshake is complete, queries flow with minimal framing overhead. There is no HTTP layer adding protocol complexity. For environments with predictable query patterns and a stable connection to a nearby resolver, DoT can be slightly faster than DoH per query because of reduced framing. It does not benefit from HTTP/2 multiplexing, but for typical DNS workloads (short queries and responses), this gap is negligible.

3. Privacy and Security in Practice

Protection Against Eavesdropping: Both protocols encrypt DNS queries end to end between your device and the resolver. A network observer sees only that traffic is flowing to a known DNS resolver IP, not which domains are being queried.

DNS Spoofing and MitM Attacks: Both protocols use TLS with certificate validation, which means the client can verify it is communicating with the intended resolver. Forged responses cannot pass TLS authentication.

A Note on Resolver Trust: Encrypting DNS traffic does not change the fact that your chosen resolver can see all your queries. If you use Cloudflare or Google as your DoH or DoT provider, they can log and analyze your queries. Encrypting DNS protects you from network-path attackers; choosing a trustworthy resolver with a clear no-logging policy addresses the resolver trust question separately.

Choosing Between DNS Over HTTPS (DoH) and DNS Over TLS (DoT)

The right choice depends on who is configuring DNS and what visibility requirements exist.

For individual users: DoH is the lower-friction option. It is already built into Chrome, Firefox, and Edge. Enabling it takes a browser settings change and a resolver selection, with no router access and no system-level configuration. DoH on port 443 also works on restrictive public networks (airports, hotels, corporate guest Wi-Fi) where port 853 is typically blocked.

For Android users: Android 9 and later support DoT natively as "Private DNS." Go to Settings → Network & Internet → Advanced → Private DNS, select "Private DNS provider hostname," and enter your preferred resolver (for example, 1dot1dot1dot1.cloudflare-dns.com). This applies DoT system-wide, not just in the browser.

For iOS users: iOS 14 and later support encrypted DNS at the OS level through configuration profiles. Providers publish ready-made profiles you can download and install via Settings > General > VPN & Device Management, applying DoH or DoT system-wide across all apps. Apple's iCloud Private Relay (available on iCloud+ plans) also encrypts DNS lookups as part of its two-hop architecture, though it routes traffic through Apple's infrastructure rather than a user-selected resolver. Note that some third-party apps (particularly VPN clients, certain browsers, and apps that bundle their own DNS resolver stacks) may issue DNS queries through their own transport layer and will not respect the system-wide configuration profile.

For businesses and network administrators: DoT is the standard choice. It operates on port 853, which keeps DNS traffic identifiable and routable through your DNS filtering and monitoring infrastructure. You can apply security policies, block malware domains, and log DNS queries using existing network tools. DoH in enterprise environments requires additional configuration to ensure browsers use your internal resolvers rather than routing DNS queries directly to Cloudflare or Google, bypassing your controls.

For larger networks: Deploy DoT on an internal recursive resolver that supports it (Unbound, BIND 9.17+). Configure firewall rules to block direct outbound traffic on port 853 to external IPs, forcing all DoT queries through your managed resolver. For DoH, configure your resolver's DoH endpoint and push the resolver URL to browsers via group policy or MDM.

# FORWARD chain: applies to traffic from LAN clients passing through this host
# Block plaintext DNS outbound to prevent clients from bypassing the resolver
iptables -I FORWARD -p udp --dport 53 -j DROP
iptables -I FORWARD -p tcp --dport 53 -j DROP

# Block direct external DoT to prevent clients from using third-party resolvers
iptables -I FORWARD -p tcp --dport 853 -j DROP

# Allow DoT only to the managed internal resolver (replace 192.168.1.10 with your resolver IP)
iptables -I FORWARD -p tcp --dport 853 -d 192.168.1.10 -j ACCEPT

# OUTPUT chain: applies to processes running directly on this gateway host
# Without these rules, local processes (cron jobs, monitoring agents, etc.)
# can still send plaintext DNS or reach external DoT resolvers directly.

iptables -I OUTPUT -p udp --dport 53 -j DROP
iptables -I OUTPUT -p tcp --dport 53 -j DROP
iptables -I OUTPUT -p tcp --dport 853 -j DROP
iptables -I OUTPUT -p tcp --dport 853 -d 192.168.1.10 -j ACCEPT

Then configure your internal recursive resolver to accept DoT on port 853 and forward upstream queries over DoT or DoH to your preferred provider. All DNS traffic stays encrypted end to end while remaining visible and policy-controlled at the network layer.

Troubleshooting Common Issues with DoH and DoT

Connection Failures: If DoH or DoT queries are not resolving, check two things first: whether the resolver endpoint URL or hostname is correct, and whether the required port is open. DoH uses port 443; if that port is blocked, no HTTPS traffic would work at all, so the issue is more likely a misconfigured resolver URL. DoT uses port 853; this port is blocked by many firewalls and may need to be explicitly permitted on your network equipment.

Slower DNS Resolution: The first query after enabling DoH or DoT takes longer than plaintext DNS because TLS negotiation adds round trips before the first DNS response. This setup latency is a one-time cost per session. If all queries are slower on an ongoing basis, the resolver may be geographically distant from your location. Switching to a resolver with a closer anycast presence typically resolves this.

Compatibility Issues: Older routers and network devices often do not support encrypted DNS and may actively interfere with DoH or DoT traffic. Firmware updates from the manufacturer are the correct fix. If a firmware update is not available, configure DoH or DoT at the device level rather than the router level.

Network Configuration Conflicts: In corporate environments, enabling DoH in a browser can conflict with internal DNS policies if the browser starts sending queries to an external provider rather than the internal resolver. The fix is to configure your internal resolver to support DoH and push that resolver URL to browsers via group policy, so encrypted DNS stays within your network infrastructure.

Fixing Configuration Issues

Verify the Resolver Endpoint: For Cloudflare DoH, the endpoint is https://1.1.1.1/dns-query. For Google DoH, it is https://8.8.8.8/dns-query. For Cloudflare DoT, the hostname is 1dot1dot1dot1.cloudflare-dns.com on port 853. For Google DoT, it is dns.google on port 853.

Test DNS Resolution: Use dig to test DoH directly: dig @1.1.1.1 whoisfreaks.com (basic DNS test) or curl 'https://1.1.1.1/dns-query?name=whoisfreaks.com&type=A' -H 'Accept: application/dns-json' (DoH test). For DoT, use kdig @1.1.1.1+853 whoisfreaks.com +tls if you have knot-dnsutils installed.

Check Firewall and Router Settings: Confirm port 443 is open for DoH and port 853 for DoT. On Linux systems, ss -tulpn shows which ports are currently open. On routers, check both inbound and outbound rules.

Update Network Hardware: If your router firmware predates 2020 and DoT is failing, a firmware update is the first step. Manufacturers including Asus, Netgear, and TP-Link have added DoT support to recent firmware revisions for many consumer routers.

Revert to Plaintext DNS for Diagnosis: Temporarily disabling DoH or DoT in your browser or OS settings and testing with standard port 53 DNS helps isolate whether the problem is specific to encrypted DNS or a general DNS issue on your network.

Conclusion: Choosing the Right Encrypted DNS Protocol

Both DNS over HTTPS (DoH) and DNS over TLS (DoT) solve a real and long-standing problem: plaintext DNS on port 53 exposes browsing behavior to anyone on the network path. Both protocols encrypt that traffic end to end and protect against eavesdropping, DNS spoofing, and man-in-the-middle attacks. The encryption strength is equivalent. The choice is an operational one.

Individuals using a browser get the most from DoH: it requires no system configuration, works on networks that block port 853, and is enabled with a few clicks in Chrome or Firefox. Network administrators and security teams get more from DoT: the dedicated port 853 keeps DNS traffic identifiable, filterable, and loggable through standard network tooling, which is essential for enforcing DNS-based security policies.

If you have not switched to encrypted DNS yet, DoH is the lowest-friction starting point. Enable it in your browser settings and select Cloudflare (1.1.1.1) or Google (8.8.8.8) as your DoH provider. For organizations managing network infrastructure, DoT on port 853 gives you the visibility you need to enforce DNS security policies without sacrificing the encryption benefits. Either choice is a meaningful improvement over plaintext DNS on port 53.

For organizations that need to monitor, analyze, or query DNS records at scale (whether for threat intelligence, domain tracking, or infrastructure mapping), the WhoisFreaks DNS API provides programmatic access to DNS record data across A, AAAA, MX, NS, TXT, CNAME, and SOA record types.

Frequently Asked Questions

1. Which is better, DNS over HTTPS or DNS over TLS?

Neither is objectively better. They solve the same problem through different mechanisms. DoH is the right choice for individual users and consumer devices because it is already integrated into browsers like Chrome and Firefox and requires no additional setup. DoT is typically preferred in enterprise environments because it operates on a dedicated port (853), which makes DNS traffic visible and controllable for network administrators managing security policies and DNS filtering.

2. What are the disadvantages of DNS over TLS?

DoT operates on port 853, a dedicated port that some firewalls block. This can prevent DoT from working on restrictive networks such as public Wi-Fi or networks with aggressive egress filtering. Configuring DoT also requires more manual setup on most operating systems compared to enabling DoH through a browser setting. DoH achieves the same encryption goal on port 443 and is far less likely to be blocked.

3. What are the risks of DNS over HTTPS?

DoH routes DNS queries through port 443 alongside normal HTTPS traffic, which makes it difficult for network administrators to inspect, filter, or log DNS queries using standard network monitoring tools. In enterprise environments, this can cause DoH to bypass internal DNS resolvers that enforce security policies such as malware domain blocking or content filtering. Organizations should configure their DNS resolvers to support DoH directly rather than allowing browsers to route DNS queries to external providers like Cloudflare or Google.

4. What does DoH stand for?

DoH stands for DNS over HTTPS. It is defined in IETF RFC 8484, published in October 2018. DoH sends DNS queries as standard HTTPS requests over port 443, wrapped inside the same HTTP/2 or HTTP/3 framing used by regular web traffic. From a network observer's perspective, DoH traffic is indistinguishable from a browser loading a website. This makes DoH resistant to detection and blocking, which is both its privacy strength and the reason enterprise network administrators treat it with caution: browsers routing DoH queries directly to external providers like Cloudflare or Google can bypass internal DNS filtering policies that rely on controlling which resolver handles queries.

5. What port does DNS over TLS use?

DNS over TLS uses TCP port 853, defined in IETF RFC 7858. Unlike DoH, which shares port 443 with all HTTPS traffic, DoT has its own dedicated port, which means it is always identifiable as DNS traffic on the wire. Network administrators can monitor, log, and apply security policies to DoT traffic without losing DNS visibility, which is a key reason enterprises prefer DoT over DoH for internal network deployments. The trade-off is that port 853 is less universally open than port 443. On restrictive networks such as public Wi-Fi, corporate guest networks, or regions with active internet filtering, DoT connections may fail silently where DoH would succeed.

6. Does DNS over HTTPS or DNS over TLS support DNSSEC?

Both DoH and DoT are compatible with DNSSEC, but they are separate mechanisms. DoH and DoT encrypt the connection between your DNS client and your recursive resolver, preventing interception in transit. DNSSEC adds cryptographic signatures to DNS records so the resolver can verify that the data came from the authoritative nameserver and has not been altered. Using either DoH or DoT together with a DNSSEC-validating resolver gives you both encrypted transport and verified record integrity.