DNS 自 1984 年起默认明文传输，虽轻量但暴露用户隐私。本文梳理 DoT、DoH、DoQ 三大标准协议的机制差异、端口特性及防火墙兼容性等部署障碍，指出加密仅保护客户端到解析器链路，递归查询链路不含客户端信息。
标准协议与端口特性：
三大协议均为 IETF RFC 标准。DoT 于 2016 年发布，直接在 TLS 层加密 DNS 内容，复用成熟 TLS 栈，占用专用端口 TCP/853。DoH 基于 HTTPS（TLS+HTTP），走通用端口 TCP/443，兼容现有安全基础设施，并继承 HTTP/2 等性能优化，更适配浏览器场景。DoQ 采用 QUIC 传输，原文未给出具体端口与 RFC 编号。三者均仅加密客户端至递归解析器的「最后一跳」（步骤 1），解析器向权威服务器的递归查询（步骤 2-4）不携带客户端标识，原文明确指出该段不存在同类隐私风险。
部署障碍与采用现状：
DoT 的专用端口 TCP/853 仍未被大量安全防火墙放行，成为公网部署的已知阻滞点。DoH 借道 TCP/443 规避此问题，但原文引用学界报告称其「并非市场上最流行的加密 DNS」，原文未给出具体份额数据。DoQ 处于早期阶段，原文未给出部署规模或兼容性数据。三协议均需解析器侧部署证书与密钥管理，客户端需显式配置或依赖发现机制，原文未给出具体发现协议细节。
威胁模型边界：
加密 DNS 仅解决旁路窃听与劫持客户端-解析器明文交互的问题，无法防范解析器自身记录查询日志、恶意解析器篡改答案、或上游递归链路被监控。原文未讨论 DNSSEC 与加密 DNS 的组合效果，亦未涉及客户端子网（ECS）在加密隧道中的传递策略。
对运维工程师而言，选型需权衡防火墙策略、客户端覆盖面与解析器运维成本：企业网若可控放行 TCP/853，DoT 实现最简；面向公网浏览器场景，DoH 兼容性最优；QUIC 成熟前，DoQ 仍属观察对象。关键动作是确认上游解析器支持的协议版本与证书有效性，并在策略层明确加密边界止于递归解析器。
原文: APNIC Blog（2023-01-19）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog