DNS-over-HTTPS vs DNS-over-TLS Which Approach Wins on Latency

As concerns about online privacy and security have intensified over the past decade, the once-overlooked Domain Name System (DNS) has become a central focus of efforts to shield user activity from surveillance and tampering. Traditionally, DNS queries were sent in plaintext, allowing intermediaries to observe, log, or even manipulate the domain lookups users made. This vulnerability led to the development of encrypted DNS protocols, most notably DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH). Both aim to prevent eavesdropping and interference by securing DNS queries in transit, but they differ significantly in their technical underpinnings, deployment scenarios, and performance characteristics. Among these differences, latency—how quickly a user gets a DNS response—is a decisive factor, especially for web browsing and application responsiveness. Understanding which protocol has the upper hand in latency requires examining their architectures, network behaviors, and real-world performance data.

DNS-over-TLS wraps DNS queries in the TLS protocol and sends them over a dedicated port, typically port 853. This approach closely mirrors the traditional DNS protocol in structure but adds encryption and integrity. It maintains a clear separation between DNS traffic and other types of internet communication, which can aid in debugging and in some cases optimize performance through network prioritization. DNS-over-HTTPS, on the other hand, sends DNS queries as HTTPS requests over port 443, the same port used by most secure web traffic. It encapsulates DNS queries in the body of HTTP requests and receives responses in standard HTTP format, layered atop TLS. This design choice has advantages in network environments where HTTPS traffic is prioritized or where middleboxes aggressively throttle or block unfamiliar protocols like DoT.

From a latency perspective, the differences begin with connection establishment. Both DoT and DoH require a TLS handshake, which introduces some delay compared to plaintext DNS. However, DoH can leverage connection reuse through persistent HTTP/2 or HTTP/3 sessions. A web browser that already maintains an open connection to a DoH resolver—for example, via HTTP/2 multiplexing—can piggyback DNS queries on that connection without requiring a new handshake. This dramatically reduces query latency for subsequent lookups. DoT, while capable of reusing connections, typically maintains one DNS session per connection and lacks the multiplexing capabilities of HTTP/2 or HTTP/3. This can result in higher latency under concurrent DNS query loads or when connections are frequently torn down and reestablished.

Another major factor influencing latency is how each protocol interacts with network infrastructure. DNS-over-TLS connections are more easily identified and can be shaped or blocked by network administrators or middleboxes. In contrast, DNS-over-HTTPS blends in with ordinary HTTPS traffic. This camouflage helps ensure delivery but also means that DoH queries may benefit from the same performance enhancements, such as CDN edge proximity and HTTP/3 support, that major websites and content providers use. For example, resolvers like Cloudflare’s 1.1.1.1 or Google’s Public DNS operate massive global networks that serve DoH requests from geographically close servers, reducing round-trip times.

The choice of transport protocol—TCP versus UDP—also matters. DNS-over-TLS, by necessity, uses TCP due to its reliance on TLS. This can lead to additional latency in networks with high packet loss or jitter, where TCP’s retransmission mechanisms are triggered. DoH, when implemented over HTTP/3, benefits from QUIC’s design, which includes faster handshakes, stream multiplexing, and resilience to packet loss. These attributes often allow DoH over HTTP/3 to outperform both DoT and DoH over HTTP/2 in lossy network conditions, especially on mobile networks where latency variance is common.

Empirical measurements from studies and real-world deployments support these theoretical observations. Tests conducted by Mozilla, Cloudflare, and independent researchers have shown that DoH over HTTP/2 or HTTP/3 often matches or exceeds the performance of DoT, particularly when connection reuse and multiplexing are leveraged. In scenarios where users are accessing multiple domains in rapid succession, such as during the loading of a complex webpage, the ability of DoH to send parallel queries over an existing secure connection leads to noticeable latency reductions. On the other hand, DoT may offer more consistent performance in scenarios where queries are sparse and resolvers are optimized for TLS handling, but this consistency often comes at the cost of higher average latency compared to optimized DoH deployments.

Nevertheless, the performance of both DoT and DoH can vary significantly depending on client and resolver implementations. For instance, some operating systems or stub resolvers may fail to efficiently reuse DoT connections, leading to redundant handshakes and increased latency. Similarly, a poorly configured DoH client may not leverage HTTP/2 features fully or may use an inefficient resolver location. These variables complicate definitive conclusions but also highlight the importance of implementation details in achieving low-latency DNS resolution.

In environments such as enterprise networks, IoT deployments, or constrained systems, DoT may still be preferred due to its simplicity and the ability to more easily segregate DNS traffic for analysis or policy enforcement. However, in consumer and browser-centric contexts, DoH’s ability to integrate with modern web stacks and benefit from persistent HTTPS infrastructure gives it a clear edge in reducing DNS resolution times.

Ultimately, while both protocols significantly enhance privacy and integrity over traditional DNS, DNS-over-HTTPS tends to win the latency race in practice. Its synergy with web protocols, superior connection reuse, and compatibility with HTTP/3 transport technologies allow it to deliver DNS responses more quickly, particularly in the kinds of multi-domain, concurrent query environments common in today’s internet usage. As the internet continues to evolve toward more secure, encrypted-by-default architectures, the performance advantages of DNS-over-HTTPS make it an increasingly attractive choice for both developers and end users focused on speed as well as security.

As concerns about online privacy and security have intensified over the past decade, the once-overlooked Domain Name System (DNS) has become a central focus of efforts to shield user activity from surveillance and tampering. Traditionally, DNS queries were sent in plaintext, allowing intermediaries to observe, log, or even manipulate the domain lookups users made. This…