摘要

  • ECS 查询中的源前缀长度约束解析器送往上游的客户端网络位数，地址字段随之截短，而不是必然包含完整地址。
  • 权威服务器在响应中返回范围前缀长度，规定答案可供哪些网络范围内的后续客户端复用；这与源前缀长度是两个独立决定。
  • 前缀和范围都不构成身份、同意或精确地理位置证明。RFC 7871 记录了隐私与缓存代价，RFC 8932 则要求隐私服务避免使用 ECS，或尽量缩短并公开其政策。

两个长度，两种权力

SOURCE PREFIX-LENGTH 出现在查询里，表示地址开头有多少位具有意义。递归解析器会设定自己愿意缓存的最大前缀，并应选择短于完整地址的长度。若收到的查询已经带有更短的限制，后续转发者不得补上更多客户端位。IPv4 或 IPv6 地址字段只保留相应前缀，并仅补齐最后一个必要字节。

SCOPE PREFIX-LENGTH 在查询中必须为零；它在响应中才表达实际范围。权威服务器用它说明多少个起始位定义了答案覆盖的网络。范围越短，答案可在越大的地址集合中复用；范围更长，则可能表示此前给出的源前缀不足以完成所需的定制选择。

这两个数字构成一种双边约束，却不是身份契约。解析器约束披露，权威服务器约束缓存影响。RFC 7871 没有规定权威方如何挑选答案，也没有说范围能保证最近、最快或最可靠的服务。拓扑距离与地理距离只存在松散联系，前缀更不能指认具体的人、设备或应用。

为什么解析器要替换自己的地址线索

通常，权威服务器看到的是递归解析器的源地址，而非最初发起查询的网络。若解析器与用户在拓扑上接近，这个线索或许够用；集中式解析器服务远处分散用户时，它自己的地址可能使定制响应偏离用户所处网络。

RFC 7871 记录的 ECS 选项，允许中间解析器把来源网络的一部分加入上游查询。它不是原样转发用户的完整地址，而是由解析器依照自己的配置截取前缀。用户可能从更合适的响应中获益，但真正同权威服务器交涉的是解析器：上游查询不是用户亲自发出的，披露长度也通常不是由用户逐次协商。

因此，协议的历史意义不只在报文增加了字段。它让中间人的政策进入报文，并把后续缓存行为交给另一中间人返回的范围。性能或本地性目标，由此获得了隐私与治理表面。

同一个名字，多个网络缓存

支持 ECS 的缓存仍先按 DNS 的名称、类型和类别查找，随后再用前缀匹配选择相关 RRset。响应所描述的网络范围与答案绑定，源长度、范围长度和解析器本地最大长度共同影响缓存项如何命中。

若响应不含 ECS，通常按范围 /0 处理，即可供所有客户端地址使用。若权威服务器返回 REFUSED，ECS 解析器会在不带 ECS 的情况下重试，以区分“拒绝这个选项”和该响应码的其他约定。

新增网络维度会拆分原本可共享的缓存。同一名称、类型与类别可能保存多组网络答案，带来内存增长、命中复用下降和服务器负载增加。RFC 7871 因而建议默认关闭，仅在客户端有明确收益时启用，并限制每个查询保留的网络与答案数，且绝不发送超出自身愿意缓存的地址位。

响应字段匹配也有明确但有限的安全作用。RFC 建议检查响应中的非零查询标识字段是否与查询一致，并丢弃不匹配结果，以缩小伪造和缓存污染路径。这并不认证客户端前缀，也不会自动使权威方的定制策略可信。

/0 是报文指令，不等于普遍可用的开关

存根解析器可把源前缀设为零。递归解析器收到后，不得把客户端地址信息加入继续发出的查询；它可以完全不带 ECS，也可以改用自身地址信息。转发链条同样不得扩大上游已经施加的限制。

不过，RFC 7871 在 2016 年也指出，软件是否把这个选择实际暴露给用户，仍是限制之一。这里必须保持历史边界：这不是对当前应用、公共解析器或运营商政策的普查，本稿的材料也不包含现时采用率。

RFC 8932 在 2020 年把问题放入 DNS 隐私服务的运营框架。客户端到解析器的加密能保护这一跳免受部分观察者窥视，但解析器仍能看到查询并把信息继续发送。最佳实践要求尊重源前缀 /0，避免上游 ECS 或提供不使用 ECS 的替代服务；若确需使用，则应发送业务上可行的最短前缀，最好限制接收它的上游，并披露真实长度与政策。

DNSSEC 没有为披露决定签名

DNSSEC 验证与 ECS 范围是两套控制。RFC 7871 建议多数 DNSSEC 记录采用 /0 范围，RRSIG 仍只绑定其签署的 RRset。验证可以按 DNSSEC 规则保护 DNS 数据，却不会认证解析器为何披露前缀、证明用户地理位置，或背书权威服务器的本地性判断。

所以，本文的结论很窄：ECS 把“披露多少客户端网络”和“答案可复用多远”分别固化为中间人的决定。这是从协议机制得出的编辑分析，不是对当今部署效果的测量。

来源