摘要

  • RFC 9539 是一项实验性安排，让递归解析器与权威服务器分别、自愿地启用端口 853 上的 DoT 或 DoQ，目标是减少被动监听，而不是建立一套新的权威认证制度。
  • 该模式明确接受无法验证身份的证书，也会在加密失败后回到 Do53。它不能抵抗主动降级或中间人，不替代 DNSSEC，也不证明实际处理的那次查询曾经被加密。
  • 审计必须同时保存按源 IP、目的 IP、传输协议形成的能力状态，以及每个查询的竞速赢家、证书判断、SNI、计时器、失败原因和明文回退。握手成功不是隐私收据。

一条明文回答先抵达

先设定一个演示场景。递归解析器第一次向权威地址 X 查询，内存中没有这个地址近期支持加密传输的记录。为了不因实验增加明显延迟，它几乎同时发出两次尝试：一条是端口 53 上的普通 DNS，另一条在端口 853 上建立 DoT 或 DoQ。

明文回答先到。它与尚未完成的查询相符，格式正确，于是被处理。随后抵达的同一问题的其他响应会被标记为已处理。几毫秒后，加密握手也成功了。解析器据此记住：从当前源地址到 X 的这个协议最近可用；在 RFC 9539 建议的三天 persistence 窗口内，后续问题可以不再同时发送 Do53。

这不是协议矛盾，而是机会式部署的取舍。问题在于观测系统容易把三件事压成一个“成功”：DNS 已取得回答、目的 IP 可完成加密握手、这一次查询保持了机密。前两项成立，第三项并不成立。若仪表盘只显示“权威 DNS 已加密”，它就删除了用户真正关心的证据。

证书又增加一层边界。RFC 9539 的递归客户端必须接受服务器呈现的任何证书。身份验证失败可以被记录，却不能仅因失败而拒绝连接并改用明文；那样会在只存在被动监听的情况下主动放弃保护。因此，这个会话可以对被动观察者保密，同时仍可能被主动中间人接管。证书被接受，不等于身份已经证明。

这是隐私实验，不是新的信任层级

RFC 9539 于 2024 年 2 月作为 Experimental RFC 发布。它关注常被“加密 DNS”讨论遗漏的一段：递归解析器已经从用户处收到问题之后，到具体权威服务器取得答案之前的路径。RFC 7858 定义 DoT，RFC 9250 定义 DoQ；RFC 9539 为它们在这段路径上的无协调采用给出状态机。

任何一侧都可以先行动。权威运营者可在端口 853 提供 DoT、DoQ 或两者；递归运营者可对普通解析流程已经找到的权威 IP 发起探测。没有新注册表宣告某个 zone 已加入，没有许可记录，也不要求整个生态同时升级。

这正是设计价值。它继承 RFC 7435 的机会式安全思想：即使暂时不能认证对端，也不要因此让所有流量保持明文。它也符合 Heng Lu 对“本地未来决定”和“自愿采用”的要求：公共规范只提供兼容做法，变化必须经过实现、部署和运行才成为现实。RFC 的发布不是全网命令，不采用也不构成无效。

边界同样清楚。该实验不认证权威服务器，不改变 DNS 委派，不给端口 853 的响应者增加任何制度权力。它无法抵抗主动攻击者强迫降级，也不替代 DNSSEC 对数据的来源认证与完整性验证。最快的路径只证明速度，不证明真实性。

能力状态属于具体路径

RFC 9539 建议按权威服务器 IP 保存传输能力，而不是只按 NS 主机名或 zone。一个 NS 名称可以解析到多个地址，一个地址也可能位于负载均衡或 anycast 集群前。若解析器把一次成功写成“这个 NS 支持 DoQ”，下次可能落到只支持端口 53 的另一台实例，凭空多出一次超时。

实际键值还可更细：解析器源 IP、权威目的 IP、传输协议。负载均衡器可能按客户端地址固定后端；anycast 路由也可能让不同来源到达不同站点。只要这些路径的部署状态不同，“服务器支持加密”就太宽泛。可复核的说法只能是：某个源，在某一时间，以某种协议，成功到达某个目的地址。

协议列出的状态正是为了保留这句话。它包括连接何时发起与完成，结果是 success、fail 还是 timeout，最后一次响应时间，可用的 resumption 信息，以及哪些查询仍挂在会话上。进程重启后，活跃 socket、待处理查询和 last-activity 不能假装继续存在；近期能力历史则可以保留。

RFC 建议三天成功记忆、一天失败抑制、四秒握手超时。这些是实验起点，不是互联网常数。高流量递归服务、卫星路径、小型权威节点或正在滚动升级的 anycast 集群都可能选择不同值。无论取值如何，都应进入公开运营记录，因为这些计时器决定一次成功可以压制明文多久，也决定一次失败会让隐私尝试停摆多久。

不能把所有失败压成一个布尔值

若加密握手失败，解析器清除会话、写入失败，并把没有其他路径覆盖的查询转到 Do53；直到 damping 结束后才再次探测。同样，会话建立后的协议错误也触发失败状态。

服务端主动、正常地关闭连接不同。权威服务器可能为了内存或 CPU 回收最久未活动的连接。尚未回答的问题仍需转到其他路径，但正常关闭不必证明该 IP 一整天都不支持加密；下一次查询可以很快重试。单个查询超时又是另一种情况，因为同一会话、另一种加密协议、另一台权威服务器或 Do53 仍可能在工作。

若日志只留下 encrypted=false，就无法判断政策是否合理。TLS alert 可能是协议不兼容；端口沉默可能是不支持、过滤或限速；clean close 可能是负责的资源管理；一个格式完整的 SERVFAIL 是 DNS 应用响应，不是传输故障。主动攻击者还能伪造部分条件以诱导明文。因此，每次降级都要关联原因、时间、受影响查询以及下次允许加密探测的时点。

这个实验默认优先保持解析可用。RFC 9539 附录解释了为什么不能随意 fail closed：一个偶然提供加密传输的权威服务器，没有通过可认证信号承诺永远提供它。未来的严格模式需要抗降级信号、服务器身份认证和明确作用域。在此之前，一旦端口 853 出故障便拒绝所有答案，会把自愿隐私增强变成新的停机杠杆。

三本密码学账不能混写

第一本账问传输是否加密。TLS 或 QUIC 成功，只能回答在该会话上传过的那些字节。第二本账问对端是否真是预期的权威服务器。RFC 9539 故意不回答，因为客户端接受任何证书。第三本账问 DNS 数据是否真实。DNSSEC 在存在有效信任链和签名数据时回答这一问题，不取决于包走 Do53、DoT 还是 DoQ。

因此，明文传输的 DNSSEC-valid 响应可以没有通道机密性，却有数据认证；未经身份验证的加密响应可以躲开被动观察，却没有证明服务器身份。若同时缺少有效 DNSSEC 链，它也没有证明数据来源。把两者统称为“安全 DNS”，会让风险失去可定位性。

SNI 还有独立泄露面。RFC 9539 建议在这种单边探测中不发送 SNI，因为明文 ClientHello 可能暴露共享 IP 上究竟是哪个 NS 名称或 zone 关系触发了查询。确有需要时，ECH 可降低泄露，但不会抹掉地址、时间和长度，也不会使证书突然获得认证效力。

RFC 7830 的 EDNS padding 与 RFC 8467 的填充策略降低长度分析；RFC 9156 的 QNAME minimisation 减少每一跳需要看到的名称内容。三者各管一个面：加密隐藏路径中的内容，最小化减少服务器收到的信息，填充削弱长度特征。它们不能彼此替代，更不负责身份认证。

同一个 IP 背后的集群也要同步

实现 RFC 9539 的权威服务必须让加密与非加密传输使用同一份 zone 数据。由于传输特征不同，响应长度、EDNS 选项和 TC 位可以不同；实质 DNS 视图不能因 listener 不同而分叉。

更现实的分叉发生在同一 IP 后面。负载均衡器可能把连续连接送到不同后端，其中一部分已升级，另一部分没有。anycast 的同一地址也可能在多个站点处于不同阶段。RFC 建议短时间内完成整个 pool 的启用、按客户端 IP 稳定映射，或让负载均衡器只把加密连接交给已知支持的成员。

这不是“集群必定一致”的保证，而是一项可测责任。运营者要按来源群组、anycast 站点和时间比较结果，记录握手成功后没有 DNS 响应的情况，并确认不同传输取得的是等价 zone generation。一次成功只描述一条路径，不能给全网集群发证书。

一行可审计证据需要什么

记录从问题开始：query ID、QNAME、QTYPE、QCLASS、创建时间；随后是解析器源地址、权威目的地址、NS 与 zone 上下文、观测点；再列出全部尝试的传输、端口、ALPN、发起与完成时间。

然后保存哪一个 outstanding queue 持有问题，最终处理了哪份响应。加密侧需要证书指纹与类型、身份验证结果、SNI/ECH、session 或 resumption 标识、early-data 状态和准确失败分类。政策侧保存当时生效的 persistence、damping 和 timeout。DNS 侧保存响应原文或哈希、RCODE、关键 flags、DNSSEC 判断和跨传输比较。

最后写入后果：本次查询是否经过 Do53、何时降级、何时可重新探测、哪个 pool/anycast 群组应答，以及什么信号会触发复核。全局报表要统计每种传输实际承载的查询比例，而不是只数曾完成过一次握手的 IP。

实验的隐私价值存在于被保护的问题里，不存在于配置文件的 listener 数量里。

资料来源