DoH 与 DoT 技术对比分析

DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 是两种常见的加密 DNS 传输方式, 它们通过不同的协议栈来实现 DNS 查询的安全传输. DoT 的标准由 RFC 7858 定义, 而 DoH 则由 DNS Queries over HTTPS (DoH) 标准化. 理解这两种技术的本质区别, 需要从网络协议层次结构入手分析.

网络协议层次结构

现代网络协议栈采用分层设计, 每一层提供不同的功能. DNS 作为应用层协议, 本身并不绑定特定的传输方式, 可以运行在多种承载协议之上.

应用层 (L7) 包含 HTTP/1.1, HTTP/2, HTTP/3, FTP 和 DNS 等协议. 值得注意的是, HTTP/3 的语义仍然在应用层, 只是 QUIC 作为传输承载. 安全层位于应用层和传输层之间, 主要包括 TLS 及其变体. TLS 通常运行在 TCP 上, 比如 HTTPS 和 DoT. DTLS 是 TLS 的数据报版本, 可以运行在 UDP 上. QUIC 协议比较特殊, 它将 TLS 1.3 的握手与密钥派生直接集成在协议内部.

QUIC 可以被视作 L4.5 层协议, 它基于 UDP 扩展, 提供了传统传输层的能力. 传输层 (L4) 包含 TCP, UDP 和 QUIC. 虽然从工程实现角度 QUIC 基于 UDP, 但它自带可靠性, 拥塞控制, 多路复用和加密握手等功能, 因此在工程上被当作独立的传输层协议. 网络层 (L3) 使用 IP 协议 (IPv4/IPv6) 负责数据包的选路和转发. 数据链路层 (L2) 包括以太网和 Wi-Fi (802.11) 等技术.

TLS 作为加密手段, 工作在应用层与传输层之间. 如果将 TLS 加密从 DoT 中剥离, DoT 本质上就变成了 DNS over TCP. 这种分层设计让加密成为可选项, 而不是协议本身的强制性约束.

Plain DNS 的特点

最普通的 DNS 称为 Plain DNS, 它可以运行在 UDP 或 TCP 上. UDP 是最常见的承载方式, 因为连接建立简单, 首次查询速度快. 但 UDP 的弱点是不可靠, 数据包容易在网络中丢失. TCP 虽然握手次数多, 首次连接速度比 UDP 慢约 30%, 但它在建立长连接后, 响应速度与 UDP 相同.

运营商在网络繁忙时会选择丢弃 UDP 报文以缓解设备压力. 对于某些运营商 UDP 丢包严重的地区, 指定使用 TCP 进行 DNS 查询可能更有利. TCP 具有重传机制, 即使丢包也能保证数据可靠到达, 而丢 UDP 包不会减少小运营商设备的负载压力, 反而会因为重试引入更多不确定性.

应用层嵌套

DNS 和 HTTP 都属于应用层协议, DoH 本质上是一个应用层协议嵌套了另一个应用层协议. DoH 不必然是 DNS over HTTPS, 使用普通的 HTTP 也是可行的, 只是未加密的 DoH 是明文请求, 相比 Plain DNS 没有任何优势, 只有极少数特殊需求场景才会使用.

理论上可以在任何应用层协议上承载 DNS, 比如 DNS over FTP 也可以实现, 只需要开发相应的服务端和客户端. 这种灵活性体现了应用层协议组合的可能性.

flowchart TD
    subgraph L7["应用层"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["安全层"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["传输层"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["网络层"]
        I[IP]
    end
    
    subgraph L2["数据链路层"]
        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

传输层嵌套

QUIC 协议基于 UDP, 同时在传输层提供了面向连接的服务. QUIC 实现了 TCP 已有的面向连接, 拥塞控制, 重传, 流量控制, 分片和组装等传输层能力. 相较 TCP, QUIC 延迟更低. 相较 UDP, QUIC 更先进且可靠.

协议组合关系

应用层和传输层之间没有必然的限制关系, 加密可以添加也可以不添加. HTTP 可以运行在 TCP 上, 也可以运行在 QUIC 上. DNS 可以运行在 TCP 上, 可以运行在 UDP 上, 也可以运行在 QUIC 上.

基于这些可能性, 可以总结出以下组合关系. Plain DNS 等于 UDP 或 TCP 加上 DNS 协议. HTTP/2 等于 TCP 加上 TLS 1.2 或 TLS 1.3 再加上 HTTP 协议. HTTP/3 等于 QUIC 加上 TLS 1.3 再加上 HTTP 协议.

DoH (DNS over HTTPS) 等于 HTTP/2 或 HTTP/3 再加上 DNS 协议. DoT (DNS over TLS) 等于 TCP 加上 TLS 1.2 或 TLS 1.3 再加上 DNS 协议. DoQ (DNS over QUIC) 等于 QUIC 加上 TLS 1.3 再加上 DNS 协议.

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

性能和兼容性分析

理解了协议层次结构之后, 可以分析 DoH 和 DoT 的优缺点.

TCP 和 QUIC 的对比需要结合运营商的实际网络环境来讨论. QUIC 是较新的协议, 解决了一些老旧网络问题, 但它毕竟基于 UDP. 从网络延迟角度看, 基于 QUIC 的协议延迟比 TCP 低约 35%, 因此 DNS over HTTP/3 和 DoQ (DNS over QUIC) 理论上会比 DNS over HTTP/2 和 DoT 性能更好.

但是实际网络环境中存在丢包导致的重传延迟问题. 运营商在网络繁忙时会选择丢弃 UDP 报文, QUIC 会被识别为 UDP 而进行丢弃. 虽然 QUIC 支持重传, 但重传引入的延迟会导致 QUIC 的实际延迟可能比 TCP 更高.

隐私和安全方面, DoH 和 DoT 都是加密流量, 不会被窃取和篡改. 关于 DoT 被识别后封锁的问题, 主要是由于 Android 系统的加密 DNS 设置默认使用 853 端口, 导致 853 端口成为敏感端口. DoT 本身是常见的普通加密流量, 不会被识别为 DNS 专用流量. 实际上任意端口都可以提供 DoT 服务, 这在 Android 上需要第三方应用来实现, iOS 上则原生支持使用任意端口的 DoT.

扩展性是 DoH 的一个重要优势. 相比 HTTP 封装的 DNS 和 Plain DNS, HTTP 具有明显更优的扩展性. 服务商可以在 443 端口上提供无数服务, 包括 DoH, 并且可以方便地扩展功能. DoT 和 DoQ 一般需要独占端口, 扩展能力完全基于 Plain DNS. 这是服务商视角的区别, 对于普通用户来说暂时没有明显感知.

DNS 请求的处理速度上, HTTP 的处理速度确实可能比 Plain DNS 慢几个 CPU 时钟周期, 但这种差异在实际使用中可以忽略不计. 兼容性方面, DoH 可能会更主流, 因为对服务商来说 DoH 扩展性好.

当前主流平台对加密 DNS 的支持情况各有不同. Chromium 内核的浏览器支持 DoH. Windows 11 系统原生支持 DoH. Android 8 及以上版本系统原生支持 DoT. Android 11 及以上版本系统原生支持 DoT 和 DoH. macOS 系统原生支持 DoT 和 DoH. iOS 系统原生支持 DoT 和 DoH.

实际选择建议

对普通用户来说, 使用 DoH 会比 DoT 省心. DoH 相较 DoT, 多数时间提供更优的延迟, 少数时间提供相似的延迟. DoH 相较 DoQ, 多数时间有相似的延迟, 少数时间提供更优的延迟.

这个结论的前提是服务商提供 DNS over HTTP/3 服务. 如果服务商不提供 HTTP/3, DoH 和 DoT 没有明显区别. DoH 会在网络质量好时, 自动使用 DoH/3 获得较低延迟, 在网络质量差时, 自动降为 HTTP/2. 这种自适应能力需要服务商实现, 不过主流服务商一般都实现了.

推荐尝试 宁屏, 它支持 DoT 和 DoH/3, 原生带广告拦截和 DNS 分流功能. 如果需要自部署, 可以使用它的 开源库.

网络协议的选择需要综合考虑多个因素, 包括运营商网络质量, 服务商支持情况, 设备兼容性等. 对于大多数用户而言, DoH 是一个平衡了性能, 兼容性和隐私保护的优秀选择.

• ←上一页
• 下一页→