Technical Comparison of DoH vs DoT

DNS over HTTPS (DoH) and DNS over TLS (DoT) are two common encrypted DNS transmission methods that implement secure DNS queries through different protocol stacks. DoT is standardized by RFC 7858, while DoH is standardized by DNS Queries over HTTPS (DoH). To understand the fundamental differences between these two technologies, we must analyze them from the perspective of network protocol hierarchy.

Network Protocol Hierarchy

Modern network protocol stacks adopt a layered design, with each layer providing distinct functionalities. DNS, as an application-layer protocol, isn’t bound to any specific transport method and can operate over various carrier protocols.

The Application Layer (L7) includes protocols like HTTP/1.1, HTTP/2, HTTP/3, FTP, and DNS. Notably, HTTP/3’s semantics remain at the application layer, though QUIC serves as its transport carrier. The Security Layer sits between the application and transport layers, primarily consisting of TLS and its variants. TLS typically runs over TCP, as seen in HTTPS and DoT. DTLS is the datagram version of TLS that can operate over UDP. The QUIC protocol is special as it integrates TLS 1.3 handshakes and key derivation directly within the protocol.

QUIC can be considered an L4.5 protocol. Based on UDP extensions, it provides traditional transport-layer capabilities. The Transport Layer (L4) includes TCP, UDP, and QUIC. Although QUIC is implemented over UDP from an engineering perspective, it incorporates reliability, congestion control, multiplexing, and encrypted handshake features, making it effectively an independent transport-layer protocol in practice. The Network Layer (L3) uses IP protocols (IPv4/IPv6) for packet routing and forwarding. The Data Link Layer (L2) includes technologies like Ethernet and Wi-Fi (802.11).

TLS operates between the application and transport layers as an encryption mechanism. If TLS encryption were removed from DoT, DoT would essentially become DNS over TCP. This layered design makes encryption optional rather than a mandatory protocol constraint.

Characteristics of Plain DNS

The most basic DNS implementation is called Plain DNS, which can operate over UDP or TCP. UDP is the most common carrier due to its simple connection setup and faster initial query speed. However, UDP’s weakness is unreliability, as packets can be easily lost in transit. Although TCP requires more handshakes (making initial connections about 30% slower than UDP), its response speed matches UDP once a persistent connection is established.

Network operators may discard UDP packets to alleviate device pressure during network congestion. In regions where certain operators experience severe UDP packet loss, specifying TCP for DNS queries might be more advantageous. TCP’s retransmission mechanism ensures reliable data delivery even with packet loss, whereas UDP packet loss doesn’t reduce load pressure on smaller operators’ equipment and may introduce more uncertainty through retries.

Application Layer Nesting

Both DNS and HTTP are application-layer protocols. DoH essentially nests one application-layer protocol within another. DoH doesn’t necessarily mean DNS over HTTPS - using plain HTTP is possible, but unencrypted DoH offers no advantages over Plain DNS since it’s cleartext. Only a few specialized scenarios would use this approach.

Theoretically, DNS can be carried over any application-layer protocol. For example, DNS over FTP could also be implemented by developing corresponding server and client components. This flexibility demonstrates the combinatorial possibilities of application-layer protocols.

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 already present in TCP, including 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 are no inherent restrictions between application and transport layers - encryption can be added or omitted. HTTP can run over TCP or QUIC. DNS can run over TCP, UDP, or QUIC.

Based on these possibilities, we can summarize the following combinations:

• Plain DNS = UDP or TCP + DNS protocol
• HTTP/2 = TCP + TLS 1.2/1.3 + HTTP protocol
• HTTP/3 = QUIC + TLS 1.3 + HTTP protocol
• DoH (DNS over HTTPS) = HTTP/2 or HTTP/3 + DNS protocol
• DoT (DNS over TLS) = TCP + TLS 1.2/1.3 + DNS protocol
• DoQ (DNS over QUIC) = QUIC + TLS 1.3 + 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

Understanding the protocol hierarchy allows us to analyze the pros and cons of DoH and DoT.

Comparing TCP and QUIC requires considering actual network operator environments. QUIC is a newer protocol that solves some legacy network issues, but it’s fundamentally UDP-based. From a latency perspective, QUIC-based protocols show about 35% lower latency than TCP-based ones, making DNS over HTTP/3 and DoQ (DNS over QUIC) theoretically better performing than DNS over HTTP/2 and DoT.

However, real-world networks face retransmission delays caused by packet loss. Operators may discard UDP packets during network congestion, and QUIC traffic identified as UDP might be dropped. Although QUIC supports retransmission, the resulting delays could make QUIC’s actual latency higher than TCP in such scenarios.

Regarding privacy and security, both DoH and DoT use encrypted traffic that can’t be intercepted or tampered with. The concern about DoT being blocked after identification mainly stems from Android’s encrypted DNS settings defaulting to port 853, making it a sensitive port. DoT itself is ordinary encrypted traffic and isn’t specifically identified as DNS traffic. In reality, any port can provide DoT services, though this requires third-party apps on Android while iOS natively supports DoT on arbitrary ports.

DoH has a significant advantage in extensibility. Compared to HTTP-encapsulated DNS and Plain DNS, HTTP offers clearly superior extensibility. Service providers can offer numerous services on port 443, including DoH, while easily expanding functionality. DoT and DoQ typically require dedicated ports, with expansion capabilities limited to Plain DNS features. This represents a service provider perspective difference, though ordinary users might not currently perceive it noticeably.

Regarding DNS request processing speed, HTTP might indeed be a few CPU clock cycles slower than Plain DNS, but this difference is negligible in practical use. In terms of compatibility, DoH might become more mainstream due to its better extensibility for service providers.

Current mainstream platform support for encrypted DNS varies:

• Chromium-based browsers support DoH
• Windows 11 natively supports DoH
• Android 8+ natively supports DoT
• Android 11+ natively supports both DoT and DoH
• macOS natively supports both DoT and DoH
• iOS natively supports both DoT and DoH

Practical Selection Recommendations

For ordinary users, using DoH might be more convenient than DoT. Compared to DoT, DoH generally offers better latency most of the time and similar latency occasionally. Compared to DoQ, DoH shows similar latency most of the time and better latency occasionally.

This conclusion assumes the service provider offers DNS over HTTP/3. If not, there’s no significant difference between DoH and DoT. When network quality is good, DoH automatically uses DoH/3 for lower latency, and falls back to HTTP/2 when network quality deteriorates. This adaptive capability requires provider implementation, which most mainstream providers already offer.

We recommend trying NullPrivate, which supports DoT and DoH/3 with native ad-blocking and DNS split tunneling features. For self-deployment, you can use its open-source library.

Protocol selection requires comprehensive consideration of multiple factors including operator network quality, provider support, and device compatibility. For most users, DoH represents an excellent choice that balances performance, compatibility, and privacy protection.

• ←Previous
• Next→