摘要

  • ECH 使 HTTPS/SVCB 记录成为实时密码配置；客户端拿到的公钥，必须与实际到达的边缘节点所持私钥匹配。
  • 应当度量 DNS 首次可见到全边缘就绪之间的错配窗口，以及接受、拒绝、retry、安全禁用和硬失败，而不是只看“已启用”。
  • retry_config 是有边界的修复机制，不是原子发布证明；持续重试或再次纠正说明 DNS、边缘批次或后端并不一致。
  • DNS、TLS 与边缘一体化的平台可以摊薄密钥托管、重叠和遥测成本；多云可迁移性需要可导出的版本回执。

DNS 记录开始携带活的密码状态

RFC 9849 把握手拆成私密的 ClientHelloInner 与路径可见的 ClientHelloOuter。真实服务器名以及 ALPN 等敏感偏好放在 inner 中，由 outer 携带加密载荷。面向客户端的服务器只有持有与 ECHConfig 对应的私钥，才能解开它。

RFC 9848 规定如何通过 DNS Service Binding 发布 ech 参数；RFC 9460 则把 SVCB/HTTPS 记录定义为一组绑定的连接指令。DNS 在这里不只是告诉客户端“去哪儿”，还告诉客户端第一只 TLS 报文应当如何加密。

于是发布顺序成了运行决策。先把密钥铺到所有边缘，再公布 DNS，需要支付双版本重叠成本；先公布，则可能把客户端送到尚不能解密的新旧交界处。证书检查可以一直正常，普通 HTTPS 也可能一直可用，但这两项都不能证明首次连接接受了 ECH。

一次连接要拼接四套状态

浏览器决定是否尝试 ECH。Chrome Enterprise 策略说明，真实使用还取决于服务器支持、HTTPS DNS 记录与 rollout 状态。Firefox FAQ记录了 Firefox 119 起默认启用，同时保留企业、家长控制和可信中间盒的禁用路径。

递归解析器决定浏览器能学到什么。RFC 9460 明确指出，压制 SVCB 解析可以否定相应安全收益。Cloudflare 运行文档列出通过解析器压制 HTTPS 回答和 canary 域进行本地控制的方式，也提示改写 HTTPS 记录可能与 DNSSEC 验证冲突。

权威 DNS 决定版本、TTL 和别名链；边缘平台决定每一批终止节点何时加载、启用与退役私钥。一份合格的轮换回执至少要把 ECHConfigList 哈希、config_id、DNS 首见时间、TTL、各边缘批次就绪时间、接受结果、重试结果和陈旧缓存尾部连在一起。

第二次成功不能抹去第一次错配

服务器可以向持有陈旧配置的客户端提供 retry 配置。这是恢复能力，却不是“第一次其实没问题”的证明。第二条连接成功，说明协议花费额外连接与延迟修复了一个真实错配。

RFC 9849 建议：如果一条连接已经基于 retry 配置发起，客户端不应再接受另一份 retry 配置。规范还把多套不一致服务器配置列为可能原因。纠正之后仍需纠正，意味着系统没有一个能落到所有节点上的权威版本。

因此，retry 必须按配置版本、解析器路径、客户端族群和边缘批次拆分。计划轮换期间短暂尾部可以受控；某一地点长期集中 retry 是配置事故。全局平均值很擅长把一整组坏节点变成一个漂亮的小数。

匿名集合也需要一致配置

ECH 的隐私目标不止是隐藏 SNI，还要求同一匿名集合里的服务在外部行为上足够相似。HelloRetryRequest cookie、密钥名称、扩展顺序或错误响应不同，都可能重新暴露后端差异。标准记录的是这种条件性风险机制；本事实包没有测得某个具名生产部署的匿名集合退化。

RFC 9849 特别讨论了 split mode 与这些可见差异。RFC 9934为 ECH 私钥和 ECHConfigList 定义 PEM 格式，并要求私钥与列表里的配置匹配。它解决了文件互操作，却不等于全网激活。控制器里格式完美的文件，在边缘证明接受之前仍只是一份愿望。

ECH 使用的 HPKE 由 RFC 9180定义。密码学可以无误地加密载荷，同时把它加密给最后一个边缘尚未拿到的密钥；这不是密码学失败，而是配置契约失败。

一体化平台的协调溢价

同时运营 DNS 与边缘的平台，可以在一个边界内完成密钥预置、就绪核验、DNS 发布、版本重叠、retry 观察与旧密钥退役。Cloudflare 文档称 Free zone 默认启用 ECH，其他套餐可配置。这不是全局成功率，却说明 ECH 可以作为平台默认能力交付。

多 CDN 域名面对更难的选择：共享一套配置、发布多条 service binding，还是允许不同路径拥有不同隐私能力。密钥托管、TTL、缓存、紧急回滚与可用性证明都会变成供应商合同。标准定义消息格式，不会替两家供应商安排变更窗口。

当一致性证据只能在单一平台的内部拓扑中查看，锁定就发生了。迁移不只是搬密钥，还要重建“当时哪里已就绪”的证据。外部哈希、时间戳、批次与接受回执，才是可迁移性资产。

关于协调溢价与锁定的结论，是从分散控制面推导出的分析判断，不是已经观测到的市场状态。域名所有者承担重叠规划与可迁移工作；DNS 提供者承担发布、TTL 与缓存证据；边缘提供者承担秘密分发、全网遥测与回滚；企业承担解析器政策测试与支持；终端用户承担首次失败和 retry 延迟。合同可以重新分配金钱与劳动，却不能让这些成本消失。

把结论交给可证伪的指标

每次轮换应保留配置哈希、DNS 观察、TTL、预期边缘集合、激活时间、首次接受率、retry、延迟、安全禁用、硬失败与回滚完成时间。

如果多轮独立测试表明：新配置只有在至少 99.999% 目标边缘可解密后才出现在 DNS，错配低于 0.01%，retry 的 p99 成本低于 25 毫秒，陈旧配置在 TTL 加 30 秒内消失，而且多供应商切换无需共享专有编排也能保持结果，那么“协调是约束”的论点应被削弱或否定。若超过 1% 的首次尝试需要 retry、某批次超过两个 TTL 仍错配，或回滚 300 秒内不能恢复，则论点增强。

这些是未来的否证阈值，不是当前市场数据。把二者分开，才能避免用精确小数包装未知事实。