摘要

  • 普通 ECS 选项只能说明查询里带有地址前缀，不能证明最初的终端用户作出了选择；转发解析器本来就可能替其客户添加 ECS。
  • 新草案把选择加入信号限定为逐跳、不可传递的指令，并要求缓存保留 ECS 来源，避免把定制答案交给从未选择加入的客户。

查询到达转发解析器时并没有 ECS。转发器为了让上游返回更贴近网络位置的答案，替客户添加了地址前缀。随后，另一台解析器在日志里看见 ECS，便把它解释成“用户同意”。从协议字段看，ECS 的确存在；从授权链看，用户从未说过这句话。

RFC 7871 允许转发解析器这样做。它也因此让一个常见推断失效：地址前缀存在，不代表发起查询的设备主动要求披露。字段记录的是技术输入，不能自动升级为授权凭证。

2026 年 8 月 20 日发布的 draft-farrokhi-dnsop-ecs-opt-in-00 试图建立一条更窄的边界。它是个人 Internet-Draft，不是 DNSOP 工作组文件，也不是 RFC。文首写着预期状态为 Experimental，选项代码仍是 TBD；这些都不能证明实现、部署或共识。它提供的是一种值得审视的责任划分：只有直接收到客户选择的递归解析器，才能把该信号作为本跳的授权输入。

地址信息与授权信息不是同一对象

EDNS Client Subnet 允许递归解析器把客户网络地址的一段前缀发送给权威服务器。权威服务器据此定制回答，例如选择更合适的服务节点。代价是客户的网络位置线索离开了递归解析器，进入多个权威端点以及可能观察到上游流量的主体。

现行 RFC 7871 模型主要由解析器配置决定是否使用 ECS。客户可发送 SOURCE PREFIX-LENGTH 为 0 的 ECS 选项退出。若希望使用非零但更短的前缀，现有 ECS 格式还要求客户提供那段前缀来自哪一个地址。位于 NAT、运营商级 NAT 或 VPN 后的设备往往不知道解析器看到的公网地址。

新草案把许可与地址分开。客户可发送新的选择加入选项，用一个字节给出最多允许转发的位数，却不必填写地址。解析器可以使用它实际观察到的查询源地址。有效长度取四个上限中的最小值：客户在新选项中的限制、查询中原有 ECS 的限制、解析器自身的最大可缓存前缀，以及 IPv4 的 32 位或 IPv6 的 128 位家族上限。

如果查询同时携带有效的非零 ECS 地址，解析器必须使用该地址，不能换成另一个地址。若地址家族不受支持、客户给出不可路由地址、来源显然不服务该地址，或解析器自行决定不用 ECS，有效长度就是 0。控制结果来自明确条件，而不是一句笼统的“支持 ECS”。

不携带才是更强的拒绝

新选项在查询中可以没有数据，也可以带一个字节。无数据形式表示允许解析器转发，但客户没有给出自己的上限，由解析器策略决定。它是广义同意，不是精确最小化。

如果客户不允许转发，草案建议直接省略新选项。显式发送数值 0 也会得到零披露，但在未加密链路上会暴露客户端实现了这一机制。省略既减少元数据，也给实现该草案的解析器一条清楚规则：没有选择加入，就不得转发客户地址信息。

不过，这个规则只约束实现者。不了解新选项的旧解析器会按照 EDNS 兼容规则忽略它，然后照常回答。因而“收到 DNS 回答”不能证明上限得到执行。兼容性保证了服务不中断，却也让成功响应无法充当隐私回执。

支持该机制的解析器会在响应中返回有效长度。选项缺失可能表示不支持，也可能表示途中被移除；而不支持的解析器仍可能按原有配置使用 ECS。客户端必须保留这种不确定性，不能用最方便的解释填空。

非传递性防止授权被复制

草案明确禁止把新的选择加入选项复制到发往权威服务器的查询，也禁止直接复制到任何上游查询。EDNS 是逐跳协商，OPT 记录本就不是可转发的全局凭证。这个选项的含义只针对直接接收客户查询的递归解析器。

转发解析器向下一台递归解析器查询时，它自己成为下一跳的客户。它可以发出新的选择加入请求，但上限不得高于原客户给出的上限。如果转发器自己构造 ECS，它应向客户报告实际转发了多少位原客户地址。如果它让上游解析器自行选择地址，上游看到的是转发器的地址，而不是原客户地址；转发器必须把原客户地址披露报告为 0。

这里没有神奇的端到端继承。每一跳只能就自己控制的行为作出决定，并且必须接受前一跳给出的更严格约束。原客户的选择不是一张可以被无限复制的通行证。薄协调的价值恰在于此：传递上限，不冒充委托。

普通 ECS 选项无法替代这条信号。既然转发器可以自行添加 ECS，单独看见 ECS 就不知道是谁作出的决定。草案因此规定，对实现它的解析器而言，仅有 ECS 而没有新选择加入选项，不足以授权转发客户地址。

缓存是第二个授权边界

地址前缀发出后，返回的定制答案可能进入缓存。草案要求解析器能够判断每一个缓存条目是否通过 ECS 获取，并禁止把 ECS 获取的答案返回给非信号客户。

这条规则处理的是容易被忽视的后果迁移。非信号客户的当前查询没有发送地址前缀，但若解析器把另一个网络的定制答案交给它，之前披露产生的结果就跨越了同意边界。答案本身没有字段说明“这是一份定制答案”，客户无法从报文还原来源。

实施者可以把信号客户与非信号客户放在不同缓存，也可以为条目保留等价的来源和资格信息。架构形式可以不同，证据义务不能消失。一个只有名称、类型、TTL 和回答内容的缓存条目，不足以执行这项政策。

对已经选择加入的客户，RFC 7871 的最长前缀匹配继续适用。即使某缓存条目的来源前缀比当前客户允许的上限更长，也可能用来回答，因为读取缓存没有向上游新发送地址信息。这说明披露上限与缓存可用性是不同判断：前者控制本次可发送什么，后者判断既有结果能否用于当前上下文。

响应值是一方陈述，不是外部证明

解析器返回的有效长度很有用，但 OPT 记录不受 DNSSEC 签名保护。DNSSEC 可以验证名称回答，却不会替解析器签署“我只转发了 N 位”这一陈述。恶意或受损解析器完全可能多发、少报。

DoT、DoH 或 DoQ 等加密传输可阻止路径攻击者增加选项、抬高上限或篡改响应值。它保护客户到解析器这一跳，不会让解析器本身变得诚实。若要证明实际披露，需要在权威侧或等价可审计位置观察收到的 ECS。

未加密路径上的攻击者可以移除、添加或修改选项。对实现草案的解析器，移除会导致不转发；添加或提高数值则可能制造客户没有授权的披露。攻击者还能伪造响应，影响客户端对能力的记忆。能力发现也应在加密通道上确认。

草案当前要求响应报告本查询的有效上限，即使答案来自缓存。此时策略上限可能为正，而本次查询实际没有向权威服务器发送任何新前缀。草案自己把“是否应报告实际使用位数”列为开放问题。政策天花板与事件事实不应共享一个含糊指标。

短前缀仍然是可传播的信息

较短前缀降低精度，但不等于匿名。它可能到达解析器发送 ECS 的每一台权威服务器，也可能被上游路径观察者看到。客户端应选择仍能获得所需效用的最短上限，同时承认这仍是网络位置证据。

同样，未来若 IANA 通过专家审查分配稳定代码，也只解决互操作编号。它不会证明缓存隔离正确、转发器没有抬高上限、解析器诚实报告，或实验具有清楚的成功标准。注册表能协调默认含义，不能替运行者承担结果责任。

这个草案最有价值的判断不是“多一个 DNS 选项”，而是拒绝让一个字段承担它无法证明的权力。客户选择、转发器策略、缓存来源、加密链路、解析器陈述与权威侧观察必须分别记录。只有这样，ECS 的出现才不会被误写成用户的同意。

来源