摘要

  • 第 12 版仍是活跃的 Experimental Internet-Draft，不是 RFC，也不是实现或部署证据。
  • /.well-known/origin-svcb 中的 HTTPS JSON 表达源站期望状态；是否允许写入 DNS 仍由运营者登记与 zone factory 政策决定。
  • regeninterval 是可能的更新频率，不是精确失效时间；源站生成、轮询、权威发布、TTL 与客户端缓存是不同的时钟。
  • 普通客户端不应绕过 DNS 直接抓取该资源，否则启动连接无法使用 ECH，还可能接收可用于跟踪的个体化配置。

一个字段装不下五只时钟

HTTPS 与 SVCB 记录把连接服务所需的参数放入 DNS。ECH 公钥配置可能频繁轮换，而 TLS 与权威 DNS 又常由不同系统管理。origin-svcb 草案提出一个同步桥：源站在 HTTPS well-known 路径提供 JSON，zone factory 轮询、校验，再生成可发布的记录。

JSON 中的 regeninterval 说明源站多快可能生成替代值。它不是证书式 notAfter，也不命令所有缓存同时失效。草案有意允许一定的时间拉伸，因为 ECH retry_configs 可以容忍版本差异，而贸然删除 HTTPS 记录或地址信息可能产生更坏的失效模式。

真正的时间链至少包括源站生成、zone factory 轮询、区文件提交、权威服务器收敛、递归与客户端缓存过期。多套 zone factory 还会增加更多时钟。只有分别记录这些事件，才能判断“新配置已生成”和“客户端已普遍看到”之间的距离。

JSON 是期望状态，不是已应用状态

一次成功的 HTTPS 抓取证明特定源站在一个证书可接受的连接上返回了文档。它不证明 zone factory 已登记该源站、内容能转换、端点通过校验、策略允许写入、DNS serial 已变化或客户端拿到新 RRset。

控制面应给每层单独命名。JSON 是期望状态；解析与策略结果是控制决定；生成的 zone fragment 是计划状态；权威 serial 与 RRset 是已应用状态；多地点探针与客户端查询才是分布式观察状态。

每张收据需要自己的身份、时间与 hash。若仪表板只保留“最后一次成功抓取”，它会把被拒绝的更新、尚未提交的更新和已完全收敛的更新显示成同一种绿色。

默认不合成是权限边界

草案要求 zone factory 默认不应根据发现的 JSON 合成记录，启用合成应需要运营者修改配置。公共路径的存在不等于 DNS 写权限。

登记收据应包含源站 URL、端口、允许的 owner name、记录类型、校验策略、负责人和生效 epoch。自动从 A/AAAA 推导 port 443 的流程可以作为可选功能，但它仍然默认关闭。

对任意兼容 SVCB 的 owner name，一般不存在天然有权控制它的 HTTP origin。zone factory 需要显式映射完整 URL 或本地来源。否则，一张用于某个 HTTPS 源站的证书可能被误读为修改其他名称或记录类型的授权。

源站只能代表自己的原点与端口

well-known URI 与 origin 和端口绑定。若后端服务位于 8443，考虑相应端口前缀 owner name 时，zone factory 必须访问那个 origin 的路径。端口 443 上的文件不能因为共享主机或地址就发现另一个端口的服务。

AliasMode 与中间商不会取消这条边界。源站可以表达别名或多个 ServiceMode 端点，但使用 CDN 或 client-facing server 时，仍由源站负责保证 JSON 准确反映当前配置。

split-mode ECH 还有一条上游信任链：后端从 client-facing server 获取参数，再把自己选择的 JSON 交给 zone factory。后端 HTTPS 文档得到认证，并不能反向证明上游参数是如何取得的。两段传递都要有收据。

能解析不代表能发布

JSON 对象包括 regeninterval 和 endpoints，未知顶层键必须忽略，空端点数组是错误。端点可以表达目标、优先级、参数或别名，但最后生成的记录仍要满足 HTTPS/SVCB 规则。

遇到无法处理的 SvcParamKey、转换失败或 zone fragment 校验失败时，zone factory 不得更新 DNS。源站未必能直接看到这一失败，所以仅统计 HTTP 200 会把拒绝写成成功。

运行台账应保存抓取状态、证书身份、正文 hash、解析结果、规范化端点集、拒绝字段、生成 RRset hash、策略版本和最终决定。还要区分“文档没有变化”“有变化但无效”“有效但被本地策略拒绝”。

一个成功端点不是整张清单

在 ECH 场景里，zone factory 应在发布前验证给出的端点能与后端完成 ECH。测试客户端可能必须使用尚未进入 DNS 的 ECHConfigList，并明确观察 ECH 是否成功。

一次连接不能批准全部列表。ECHConfigList 可能因 GREASE 故意包含不能工作的值。multi-CDN 环境有多个地址，zone factory 却可能只触达其中一个。若 ipv4hint 或 ipv6hint 与 A/AAAA 不同，应在每个相关地址验证 webPKI 身份。

校验收据要有分母：端点、地址族、ECHConfig 索引、预期 GREASE 行为、证书名、ALPN、端口、测试时间和结果。“ECH 通过”如果没有覆盖范围，不能授权发布整组端点。

分布式发布会产生分叉

转换或策略失败可能对源站不可见。zone factory 必须提供可追踪的报告，否则源站继续轮换，DNS 却停留在旧代。

多个 zone factory 还可能得出不同结论。一套理解某个参数并发布，另一套拒绝；一套按本地政策调整 TTL，另一套保持输入。它们都可以成功抓取同一 JSON，却生成不同权威回答。

对账单位应是规范化后的 RRset 语义，而不是原始 JSON 文本。空白与成员顺序变化可能不改变 DNS，本地修正却可能让相同输入产生不同记录。文档 hash、生成 RRset hash 和政策版本都要保存。

退出不是普通失败

第 12 版没有规定怎样把源站加入或移出轮询清单，也没有规定 client-facing server 怎样要求删除所有 HTTPS 记录。若参与者退出但旧 JSON 留在原处，zone factory 可能继续轮询并发布不再期望的记录。

撤回流程要写明授权者、生效时间、替代或删除方案、最后一次成功轮询、zone serial 和缓存排空观察。HTTP 404 不能自动成为删除 DNS 的命令，因为它可能来自短暂故障或路由错误；但因为删除含义不清而无限保留，也会让旧端点持续存在。

领导层必须提前决定不同参数的失败状态。ECH、地址提示、别名和其他服务参数未必适合相同的保留期限。

普通客户端不应走控制通道

well-known 资源可能公开可达，但草案明确指出普通 HTTP 客户端不应拿它代替首选 DNS 解析器的 HTTPS/SVCB 查询。直接启动连接还不能使用 ECH，会暴露 ECH 想保护的名称与 ClientHello 信息。

源站也可能对单个抓取者返回独特配置，形成意外跟踪标识。DNS 分发与缓存具有不同的聚合和政策属性；内容相似不代表控制接口可以兼任客户端发现接口。

客户端证据应包括 RRset 来源、解析路径、缓存年龄、所选端点、ECHConfig 与握手结果。JSON 抓取属于 zone factory 运维，不属于应用成功路径。

短时失守可能留下长影子

错误 DNS 值可能造成隐私泄漏，或因频繁使用 retry_configs 降低服务。草案还指出 webPKI 经常依赖 DNS 或 HTTP 来证明名称控制。若临时入侵者能修改 JSON，又碰上薄弱的地址与证书验证链，短期控制可能帮助形成更持久的 DNS 或证书影响。

这是一项风险分析，不是已经发生攻击的证据。应比较地址提示与 A/AAAA，在全部相关地址验证 webPKI，并避免让证书验证只依赖来自同一被攻陷源站的路由提示。zone factory 若也管理 CAA，还可把签发时的授权记录纳入判断。

若 well-known 路径直接映射文件系统，还必须阻断目录遍历与枚举。公开 JSON 放的是 ECH 公共材料，绝不能让相邻的私钥文件也被暴露。

资料与边界

冻结资料包括第 12 版及其官方记录、历史与引用；TLS 工作组；SVCB/HTTPS；ECH DNS 引导；ECH；well-known URI；TLS 1.3；ACME；CAA；IANA well-known 与 DNS-SVCB 注册表；以及 key-share-prediction 草案。

这些资料只确立协议、注册与风险分析文本，不证明任何 zone factory、DNS 运营者、CDN 或客户端已经部署，也不证明真实 JSON、DNS 更新、ECH 成功、缓存收敛、证书签发、跟踪、入侵、隐私泄漏或应用结果。开篇是用于检验证据链的构造案例。

来源