Comparative Technical Analysis of DoH and DoT

DNS over HTTPS (DoH) and DNS over TLS (DoT) are two common encrypted DNS transport methods that implement secure transmission of DNS queries through different protocol stacks. The DoT standard is defined by RFC 7858, while DoH is standardized by DNS Queries over HTTPS (DoH). Understanding the essential differences between these two technologies requires analysis starting from the network protocol hierarchy.

Network Protocol Hierarchy

Modern network protocol stacks adopt a layered design, with each layer providing different functions. As an application layer protocol, DNS itself is not bound to a specific transport method and can run over various bearer protocols.

The Application Layer (L7) includes protocols such as HTTP/1.1, HTTP/2, HTTP/3, FTP, and DNS. It is worth noting that HTTP/3 semantics remain in the application layer, with QUIC acting as the transport bearer. The Security Layer sits between the Application Layer and the Transport Layer, primarily including TLS and its variants. TLS typically runs over TCP, such as in HTTPS and DoT. DTLS is the datagram version of TLS and can run over UDP. The QUIC protocol is quite special; it integrates the TLS 1.3 handshake and key derivation directly inside the protocol.

QUIC can be viewed as a Layer 4.5 protocol; it extends UDP and provides traditional transport layer capabilities. The Transport Layer (L4) includes TCP, UDP, and QUIC. Although from an engineering implementation perspective QUIC is based on UDP, it brings features like reliability, congestion control, multiplexing, and encrypted handshakes, so it is treated as an independent transport layer protocol in engineering. The Network Layer (L3) uses the IP protocol (IPv4/IPv6) responsible for packet routing and forwarding. The Data Link Layer (L2) includes technologies like Ethernet and Wi-Fi (802.11).

As an encryption method, TLS operates between the Application Layer and the Transport Layer. If TLS encryption is stripped from DoT, DoT essentially becomes DNS over TCP. This layered design makes encryption an option rather than a mandatory constraint of the protocol itself.

Characteristics of Plain DNS

The most basic DNS is called Plain DNS; it can run over UDP or TCP. UDP is the most common bearer method because connection establishment is simple and the first query speed is fast. However, UDP’s weakness is unreliability; packets are easily lost in the network. Although TCP requires more handshakes and the first connection speed is about 30% slower than UDP, after establishing a long connection, its response speed is the same as UDP.

ISPs (Internet Service Providers) may choose to drop UDP packets to relieve device pressure when the network is busy. For regions where certain ISPs have severe UDP packet loss, specifying the use of TCP for DNS queries may be more beneficial. TCP has a retransmission mechanism, ensuring data arrives reliably even if packets are lost. Dropping UDP packets does not reduce the load pressure on small ISP devices; instead, it introduces more uncertainty due to retries.

Application Layer Nesting

Both DNS and HTTP belong to the application layer protocols. DoH is essentially one application layer protocol nesting another application layer protocol. DoH is not necessarily DNS over HTTPS; using plain HTTP is also feasible. However, unencrypted DoH is a plaintext request and offers no advantage over Plain DNS, so it is only used in very few special requirement scenarios.

Theoretically, DNS can be carried over any application layer protocol; for example, DNS over FTP can also be implemented by simply developing the corresponding server and client. This flexibility demonstrates the possibilities of application layer protocol combinations.

flowchart TD
    subgraph L7["Application Layer"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["Security Layer"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["Transport Layer"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["Network Layer"]
        I[IP]
    end
    
    subgraph L2["Data Link Layer"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

Transport Layer Nesting

The QUIC protocol is based on UDP while providing connection-oriented services at the transport layer. QUIC implements transport layer capabilities that TCP already has, such as connection orientation, congestion control, retransmission, flow control, fragmentation, and reassembly. Compared to TCP, QUIC has lower latency. Compared to UDP, QUIC is more advanced and reliable.

Protocol Combination Relationships

There is no inevitable restrictive relationship between the application layer and the transport layer; encryption can be added or not. HTTP can run over TCP, and it can also run over QUIC. DNS can run over TCP, it can run over UDP, and it can also run over QUIC.

Based on these possibilities, the following combination relationships can be summarized. Plain DNS equals UDP or TCP plus the DNS protocol. HTTP/2 equals TCP plus TLS 1.2 or TLS 1.3 plus the HTTP protocol. HTTP/3 equals QUIC plus TLS 1.3 plus the HTTP protocol.

DoH (DNS over HTTPS) equals HTTP/2 or HTTP/3 plus the DNS protocol. DoT (DNS over TLS) equals TCP plus TLS 1.2 or TLS 1.3 plus the DNS protocol. DoQ (DNS over QUIC) equals QUIC plus TLS 1.3 plus the DNS protocol.

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH over HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH over HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

Performance and Compatibility Analysis

After understanding the protocol hierarchy, we can analyze the pros and cons of DoH and DoT.

The comparison between TCP and QUIC needs to be discussed in the context of the ISP’s actual network environment. QUIC is a newer protocol that solves some older network issues, but it is after all based on UDP. From a network latency perspective, protocols based on QUIC have about 35% lower latency than TCP. Therefore, DNS over HTTP/3 and DoQ (DNS over QUIC) theoretically offer better performance than DNS over HTTP/2 and DoT.

However, in actual network environments, there are retransmission delay issues caused by packet loss. When the network is busy, ISPs may choose to drop UDP packets, and QUIC will be identified as UDP and dropped. Although QUIC supports retransmission, the delay introduced by retransmission may result in QUIC’s actual latency being higher than TCP.

Regarding privacy and security, both DoH and DoT are encrypted traffic and cannot be stolen or tampered with. Regarding the issue of DoT being blocked after identification, this is mainly because the Android system’s encrypted DNS setting uses port 853 by default, making port 853 a sensitive port. DoT itself is common ordinary encrypted traffic and will not be identified as DNS-specific traffic. In fact, any port can provide DoT service; this requires third-party apps to implement on Android, while iOS natively supports DoT using arbitrary ports.

Scalability is a significant advantage of DoH. Compared to HTTP-encapsulated DNS and Plain DNS, HTTP has significantly better scalability. Service providers can offer countless services on port 443, including DoH, and can easily extend functionality. DoT and DoQ generally require dedicated ports, and their extension capabilities are entirely based on Plain DNS. This is a difference from the service provider’s perspective; for ordinary users, there is currently no obvious perception of this.

In terms of DNS request processing speed, HTTP processing speed may indeed be a few CPU clock cycles slower than Plain DNS, but this difference is negligible in actual use. In terms of compatibility, DoH is likely to become more mainstream because DoH has good scalability for service providers.

Current mainstream platforms have varying levels of support for encrypted DNS. Browsers with the Chromium kernel support DoH. The Windows 11 system natively supports DoH. Android 8 and above natively support DoT. Android 11 and above natively support DoT and DoH. The macOS system natively supports DoT and DoH. The iOS system natively supports DoT and DoH.

Practical Selection Advice

For ordinary users, using DoH is less hassle than using DoT. Compared to DoT, DoH provides better latency most of the time and similar latency a small amount of the time. Compared to DoQ, DoH has similar latency most of the time and provides better latency a small amount of the time.

The premise of this conclusion is that the service provider offers DNS over HTTP/3 service. If the service provider does not provide HTTP/3, there is no significant difference between DoH and DoT. DoH will automatically use DoH/3 to achieve lower latency when network quality is good and automatically downgrade to HTTP/2 when network quality is poor. This adaptive capability requires implementation by the service provider, though mainstream service providers have generally implemented it.

I recommend trying NullPrivate; it supports DoT and DoH/3, and natively includes ad blocking and DNS splitting functions. If you need to self-deploy, you can use its open-source library.

The choice of network protocol requires a comprehensive consideration of multiple factors, including ISP network quality, service provider support status, and device compatibility. For most users, DoH is an excellent choice that balances performance, compatibility, and privacy protection.

• ←Previous
• Next→