2026 年 3 月底，Quad9 正式在其全球解析器网络中启用 DNS over HTTP/3（DoH3）与 DNS over QUIC（DoQ）。这一更新并非简单的协议叠加，而是基于 QUIC 协议重新构建传输层安全体系的系统性工程。对于关注网络隐私与 DNS 基础设施的技术团队而言，理解 DoH3 与 DoQ 的底层差异、QUIC 相对于传统 TCP+TLS 的架构优势，以及 Quad9 在全球部署中采用的工程参数，有助于在实际系统中做出更精准的协议选型与配置决策。
QUIC 协议：作为 DNS 传输层的架构优势
理解 DoH3 与 DoQ 的技术价值，首先需要理解它们共同依赖的 QUIC 协议在设计层面解决了哪些传统 DNS 传输协议的固有问题。传统的 DNS over TLS（DoT）使用 TCP 作为传输层，TLS 作为加密层，这种分离式架构在实践中存在若干被低估的隐私与性能缺陷。
当客户端与 DoT 服务器建立连接时，TCP 三次握手必须先于 TLS 握手完成。这意味着一次完整的连接建立至少需要两个完整的往返周期（Round Trip Time，RTT），在网络延迟较高的环境中会显著影响 DNS 查询的响应时间。更关键的是，TCP 协议本身携带的元数据 —— 包括包序列号、连接标志位、窗口大小信息等 —— 即使在 TLS 加密保护下仍然暴露在网络路径上的观察者眼中。这些传输层信息无法被 TLS 单独保护，因为 TLS 运行时 TCP 连接已经建立，相关元数据已经被发送到网络中。
QUIC 协议从根本上改变了这一架构。QUIC 将加密作为核心设计目标而非事后加装的附件，每一个 QUIC 连接从初始化阶段就强制使用 TLS 1.3 进行加密，不存在明文模式。更重要的是，QUIC 保护了更多传输层信息，包括数据包编号和部分头部字段，这使得路径上的观察者即使能够看到流量的存在，也难以推断出连接状态、数据传输方向等敏感信息。从隐私保护的角度来看，这种全链路加密能力是 QUIC 相对于 TCP+TLS 组合最本质的提升。
在性能层面，QUIC 合并了传输层握手与加密层握手。客户端可以在第一个数据包中同时携带传输层初始化信息和加密握手内容，将完整的连接建立过程压缩至一个 RTT 之内。DNS 查询对延迟高度敏感 —— 每一个毫秒的改进都会直接影响终端用户的体验 —— 这种握手优化在实践中具有可感知的性能收益。此外，QUIC 原生支持连接迁移（Connection Migration），即当客户端在 Wi-Fi 与蜂窝网络之间切换时，已建立的加密会话可以无缝保持，无需重新握手。传统的 TCP 连接在网络切换时会中断并需要重建，这一特性对于移动设备上的 DNS 客户端尤为重要。
Quad9 要求所有 DoH 连接至少使用 TLS 1.2，而 QUIC 协议强制使用 TLS 1.3，这一要求进一步提升了加密层的密码学安全强度。
DNS over HTTP/3：与现有 DoH 基础设施的无缝衔接
DoH3 本质上是 RFC 8484 定义的 DNS over HTTPS 协议在 HTTP/3 之上的实现。HTTP/3 底层采用 QUIC 作为传输协议，因此 DoH3 继承了 QUIC 的全部安全与性能特性，同时保持了与现有 DoH 生态系统的兼容性。
对于已经配置使用 Quad9 DoH 端点（https://dns.quad9.net/dns-query）的客户端，无需任何配置变更即可自动获得 DoH3 支持。这一无缝过渡的实现依赖于 Quad9 部署的多层协议发现机制。客户端可以通过三种主要途径发现并升级到 HTTP/3：DDR（Discovery of Designated Resolvers）机制通过查询 \_dns.resolver.arpa 的 SVCB 记录获取解析器支持的加密传输类型；已经知道解析器主机名的客户端则查询 dns.quad9.net 的 SVCB 和 HTTPS 记录以获取协议能力；对于最初使用 HTTP/2 建立连接的客户端，Quad9 在响应头中返回 alt-svc 字段，指示客户端可以尝试升级到 HTTP/3。
这些发现机制的组合确保了不同实现深度的客户端都能找到适合自己的升级路径。值得注意的是，现代 Chrome 及基于 Chromium 的浏览器已经实现了这些协议发现逻辑的自动处理，用户无需手动干预即可在支持的 网络环境下使用 DoH3。
从工程角度来看，DoH3 部署的一个关键优势在于它复用了现有的 HTTPS 基础设施。DoH 协议最初被广泛采用的主要原因之一就是能够将 DNS 流量伪装成普通 HTTPS 流量，利用 CDN 和边缘节点的成熟部署降低部署门槛。DoH3 延续了这一优势 ——HTTP/3 与 QUIC 已经在全球 web 生态系统中得到广泛支持，相关客户端库和工具链已经成熟，这降低了 Quad9 在服务端和客户端两侧的维护成本。
DNS over QUIC：独立协议的工程定位
DoQ（RFC 9250）代表了一种不同的设计思路。与 DoH3 将 DNS 封装在 HTTP/3 内部不同，DoQ 直接在 QUIC 之上传输 DNS 消息，完全跳过了 HTTP 层。这种简化带来了几个显著的技术特征。
首先，DoQ 使用独立的端口 853，这与 DoT 使用的端口相同。对于已经在防火墙或网络策略中为 DoT 开放了 853 端口的组织，DoQ 的部署不会引入额外的端口变更需求。其次，由于省去了 HTTP 层的序列化与反序列化开销，DoQ 的协议头部更精简，在理论上具有更低的每查询开销。然而，更重要的差异体现在协议栈的复杂度上：DoQ 不需要 HTTP 客户端实现，这使得它在嵌入式系统、路由器固件或资源受限的环境中更容易实现和部署。
Quad9 在全球范围内提供 DoQ 支持，这一决策的考量超越了单纯的技术优化。DoQ 相对于 DoH 和 DoT 仍处于更早的采用阶段 —— 客户端库的实现数量较少，操作系统级别的原生支持也不如 DoT 成熟。Quad9 通过在全球部署生产级 DoQ 解析器，为客户端开发者、路由器固件维护者和隐私软件作者提供了真实可用的测试基础设施。这种先部署后推广的策略与 Quad9 早期部署 DoT 时的思路一致：仅靠协议规范无法推动生态系统的采纳，生产环境的可用性才是关键。
从实际部署的角度来看，当前主流操作系统对 DoQ 的支持程度差异较大。Linux 平台的系统 DNS 解析器（如 systemd-resolved）在较新版本中开始实验性支持 DoQ，但 macOS 和 Windows 原生尚无内置的 DoQ 客户端。因此，DoQ 目前更适合技术团队在特定场景下主动启用 —— 例如在自研的 DNS 客户端或企业内网工具中 —— 而非作为面向终端用户的默认选项。
统一的协议矩阵与选型建议
Quad9 的 DoH3 与 DoQ 部署覆盖了全部解析器变体，包括过滤解析器、非过滤解析器以及 ECS（EDNS Client Subnet）启用的端点。这意味着无论用户选择哪种 Quad9 服务类型，都可以获得一致的协议支持。对于技术团队而言，这意味着协议选择可以完全基于场景需求而不必担心后端兼容性。
在协议选型的工程实践中，可以遵循以下基本框架：如果客户端已经配置了 DoH 且希望在不改变配置的情况下获得 QUIC 带来的隐私与性能改进，DoH3 是最省力的选择 —— 所有实现过 SVCB/alt-svc 发现的现代客户端会自动升级。如果场景对协议栈的简洁性有更高要求，或者需要运行在 HTTP 库不可用的受限环境中，DoQ 是更直接的选择。如果网络环境限制了 UDP 流量（QUIC 的底层依赖），则需要回退到 DoT 或传统 DoH。
Quad9 明确指出，当网络路径上的中间设备阻止了 UDP 流量或 QUIC 协商时，DoH3 可能无法建立 —— 因为 HTTP/3 依赖 QUIC 而 QUIC 基于 UDP。在这种情况下，DoT（TCP 端口 853）或传统 DoH（HTTP/2 over TCP）仍然是可靠的备选方案。技术团队在配置客户端时应建立清晰的降级策略，确保在 QUIC 不可用的网络中仍能完成 DNS 解析。
监控与调优的关键指标
对于在生产环境中部署 DoH3 或 DoQ 的技术团队，建议监控以下核心指标以评估协议的实际表现：
连接建立时间（Time to First Response）是最直接的延迟指标。QUIC 合并握手的特性应该在这一指标上明显优于 TCP+TLS 组合。在实际部署中，可以对比同一客户端在使用 DoT 与 DoQ 时的首次查询响应时间，观察是否存在可感知的差异。
协议协商成功率反映了网络路径对 QUIC 的兼容性。如果 DoH3 或 DoQ 的连接失败率显著高于 DoT，可能表明网络中的防火墙或代理设备正在阻止 QUIC 流量或 UDP 端口 443/853。此时应检查相关设备是否启用了对 QUIC 的深度包检测（DPI）或直接丢弃了 UDP 流量。
连接迁移成功率是移动场景下的关键指标。当客户端在网络切换期间保持 DNS 查询的连续性时，QUIC 的连接迁移能力应当生效。如果在 Wi-Fi 与蜂窝网络之间切换时出现 DNS 查询中断或明显延迟，需要检查客户端是否正确实现了 RFC 9000 定义的连接迁移机制。
最后，TLS 握手失败率应当保持在极低水平。QUIC 强制使用 TLS 1.3，任何握手失败都可能表明服务端证书配置异常或客户端的 TLS 实现存在兼容性问题。
技术落地的下一步
Quad9 在全球解析器网络中部署 DoH3 与 DoQ，标志着公共 DNS 服务在传输层隐私保护方面进入了新的阶段。QUIC 协议从设计层面解决了传统 TCP+TLS 组合在元数据保护和连接效率上的固有缺陷，而 DoH3 与 DoQ 则提供了两条不同路径来实现基于 QUIC 的加密 DNS 传输。
对于技术决策者而言，当前的部署状态已经足以支持在生产环境中启用这些协议。DoH3 适合作为大多数场景的默认选项，它与现有 DoH 配置的兼容性降低了迁移成本，同时自动升级机制减少了运维负担。DoQ 则为需要更精简协议栈或特定嵌入场景的团队提供了有价值的替代方案。随着客户端库和操作系统级支持的逐步完善，DoQ 的采用率有望在未来一至两年内显著提升。
资料来源：Quad9 官方博客（2026 年 3 月 31 日）、RFC 9250（DNS over QUIC）、RFC 8484（DNS over HTTPS）