摘要

  • 2026 年 8 月 1 日发布的 DNS Filtering Transparency 工作组草案，传递的是过滤资料库运营者标识与事件标识，并不是已经认证的过滤原因。草案明确保留了解析器决定披露哪个资料库、何时披露的空间，也承认解析器可能把真实存在的资料条目错误地关联到一次查询。
  • 应用还要进行第二次筛选：它保存 IANA 拟议注册表的本地副本，决定支持或信任哪些资料库，并选择是否向用户展示。注册表解决标识与 URI 模板的对应关系，却不为事件记载、政策依据或执行合法性背书。
  • 用户是否打开链接是第三项决策，因为访问事件页面可能同时暴露 IP 地址和对敏感域名的查询兴趣。可问责的披露链回执必须分别记录解析器的选择、应用的呈现和用户的访问，而不能把三者压成一句“DNS 已解释原因”。

设想浏览器没有只显示一个模糊的失败页，而是告诉用户：这次 DNS 查询受到过滤，进一步说明可以在某个公开条目中查看。这样的通知比 SERVFAIL、伪造地址或空答案有用得多。用户至少知道自己面对的可能不是普通故障，也可能找到误判申诉入口。

问题在于，屏幕上的一句话并非从过滤动作原样传来。它经过一条短小却真实的发布链。解析器先决定附带哪些资料库条目；浏览器或操作系统再决定承认哪些资料库，并把哪一条变成可见链接；最后，用户要决定是否发起另一条网络请求去读取说明。

这三者拥有不同的控制面、证据和利益。若审计记录只留下最终截图，就会把选择后的通知误当成完整事实：看不见解析器没有发出的条目，看不见应用拒绝展示的条目，也看不见用户为了保护隐私而没有打开的条目。

草案送来的是索引，不是裁决

draft-ietf-dnsop-filtering-transparency-00 在结构化 DNS 错误数据中定义了 fdbs 列表。每个元素由 db 和 id 组成：前者标识一个过滤事件资料库的运营者，后者标识该资料库中的具体条目。同一列表里的多个元素必须指向同一底层事件。

应用不会直接信任解析器塞进响应的任意网址。它要在本地保存一份拟议的 DNS 过滤资料库注册表，用 db 找到一级或二级 URI 模板，再把 id 代入模板。这道间接层很重要：用户临时接入的网络及其解析器，不能仅凭一段自由文本或任意链接，就借用浏览器界面获得可信外观。

然而，模板约束只约束“怎样找到页面”，并不证明“为什么应该找到这页”。草案的安全考虑坦率承认，它无法认证应用所经历的过滤事件与所呈现资料之间确实存在关联。控制解析器的一方可以复用一个能够正常打开的 db/id 组合，却把它挂在无关查询上。

于是，一个链接可访问，只能证明该地址上有内容。它不能证明解析器选对了事件，不能证明资料库记录完整，不能证明某项法律命令真实、有效或适用于当前用户，也不能证明过滤规则只影响预定目标。协议传递了一条可核查线索，但没有替任何机构完成事实裁决。

草案自身的状态也要如实保留。00 版是 DNSOP 已接纳的工作组 Internet-Draft，取代了此前的个人草案；它仍不是 RFC，目前页面也没有列出拟议 RFC 状态。可以研究、试验和讨论这套机制，但不能提前把它写成 IETF 已经确立的部署义务。

第一项决策：解析器披露什么

草案没有要求解析器必须传递某一项具体资料。解析器自行选择支持哪些资料库运营者，也可以用自己的机制判断何时、对哪种过滤事件附带链接。这意味着出现在响应中的列表从一开始就是选择结果，而不是所有相关说明的自然全集。

同一次过滤可能有两个公开资料源，解析器却只支持一个；内部策略可能尚未映射到外部事件号；某类安全过滤可能只提供申诉联系方式，不提供公共页面；另一项义务又可能限制可披露内容。列出这些可能性不是替任何遗漏开脱，而是为了守住证据边界：输出列表并不等于完整列表。

因此，没有 fdbs 不能反推没有过滤、没有命令、没有事件记录或没有纠错渠道。它只证明应用收到的这份响应里没有可用的资料库引用。更何况，草案还指出，并非所有应用架构都能取得底层 DNS 响应细节；解析器即使发送了信息，宿主系统也可能没有把它交给最终应用。

解析器侧的治理记录应当保存响应时间、DNS 服务关系是否经过认证、EDE 类别、实际发出的运营者与事件标识、触发选择的规则，以及系统是否知道却没有发送其他候选条目。敏感域名和用户身份应实行最小化与受限保管，但“发生过一次选择”这件事不能在日志压缩时被抹掉。

第二项决策：应用让谁的说明进入界面

收到 fdbs 以后，浏览器、操作系统或其他客户端成为分发者。草案预期不同应用支持不同的资料库运营者，并要求它们判断哪些错误信息值得展示。判断可以考虑解析器身份、资料库运营者身份和本地配置。

这不是纯粹的排版动作，而是在决定哪一种机构叙述能抵达用户。两台设备收到完全相同的 DNS 字节，一台可能认识 db 并显示链接，另一台可能尚未收录该标识；一台只在响应来自显式配置的解析器时信任它，另一台还会检查资料库白名单；某个平台把结构化字段交给浏览器，另一个平台则不暴露。

所以，最终界面不是上游响应的完整镜像。单凭“用户没有看到说明”，无法判断是解析器没有发、应用不认识、信任策略拒绝，还是宿主根本没把字段传上来。相反，用户看到了链接，也只说明应用愿意分发它，并不等于应用验证了背后的过滤依据。

本地注册表副本还引入了时间差。拟议注册表把运营者标识映射到 URI 模板，条目联系人可以更新模板；草案同时提醒运营者，应用更新本地副本可能经历很长延迟。事后复盘某天用户会被带到哪里，不能只查今天的注册表，还必须知道当时客户端使用哪一份快照。

“已经登记”也不是质量认证。草案建议采用先到先得政策，同时允许 IANA 拒绝欺骗性或虚假申请。RFC 8126 对先到先得的定义更为明确：通常只检查格式和重复，不进行实质审查。注册表回答的是某个标识对应哪个模板，不回答资料库叙述是否准确、公正或具有法律权威。

应用侧回执因而需要记录注册表快照日期或哈希、实际展开的模板、支持列表与信任政策版本、接受和抑制了哪些条目、决定理由类别，以及最终呈现给用户的通知类型。没有这些字段，排障时很容易把应用的静默归咎于解析器，或把过期模板造成的失败误判为资料库不存在。

第三项决策：为了知道原因，要不要再暴露一次

事件详情不在 DNS 响应本身。用户打开链接时，客户端会连接资料库运营者。对方可能看到用户 IP，并得知这个地址上的某人曾尝试解析一个受到过滤的域名。对于政治、健康、宗教或其他敏感名称，“查询为什么被拦”本身就可能形成风险信号。

因此草案设置了清晰的动作边界：如果没有代理等隐私保护机制，应用不得在缺少用户明确操作时自动抓取事件页面。它还警告，若解析器与资料库运营者串通，或同一方同时扮演两个角色，就可能用唯一事件标识跨请求关联活动。

合理的产品可以先告诉用户“这里存在进一步资料”，而不预取页面。它可以说明请求将发往谁，区分直接访问与受保护访问，并确保同意发生在网络请求之前。合规记录也不必保存“谁在什么时间查询过哪个敏感域名”的完整清单，只需证明自动抓取没有发生、用户动作先于访问、采用何种路径，以及请求是否成功。

这项最小化不能被事后审计冲垮。为了证明系统尊重隐私而建立更全面的用户—域名—事件日志，会让解释机制变成新的观察系统。治理的目标是保留决策因果，而不是积累不必要的个人轨迹。

结构化、加密和登记各自只解决一层问题

过滤透明度草案依赖更早的 Structured Error Data for Filtered DNS。后者允许客户端解析联系信息、理由、组织和细分类别，但明确要求：这些字段未经适当验证，不得自动信任、自动展示或用于影响安全决策；结构化交换还应通过加密 DNS 传输。

这里有一组容易被混淆的边界。结构化让机器能处理，不让内容自动变真；加密保护传输免受被动窥视，不证明端点陈述准确；注册 JSON 名称或资料库标识，稳定的是语法和寻址，不是制度权威。新的 fdbs 增加了一层上下文，也同时增加了一层需要说明的选择。

RFC 7754 则把链条向上游延伸：制定过滤政策的一方和执行政策的一方可能不同。从法律、行政规则、运营商政策到技术实现，中间会发生多次翻译和变形，每一步都可能带来意外影响。及时通知有助于纠正误伤，却不会替用户判断具体过滤是否合法、合乎伦理或具有何种管辖效力。

一张三段式披露链回执

Daniel Kade 提议把回执分为三个相互链接的部分。解析器部分保存观察到的响应、可得的认证上下文、EDE 信息、发出的 db/id 组合、选择规则和已知遗漏状态。应用部分固定注册表快照、实际模板、受支持运营者列表、信任政策、呈现决定和通知类别。用户动作部分只记录是否提供访问、明确动作是否先于请求、是否经过隐私代理，以及访问结果。

回执必须容纳未知。解析器身份没有认证，就明确标成未认证；不知道为何没有发送某个条目，就不补写原因；客户端快照过期，就保存当时日期，而不是用今天的注册表覆盖；事件页面后来更新，也不能假装当前内容就是用户当时可能看到的内容。若另有法院命令、企业政策或申诉记录，应作为独立来源另行链接，而不能从 db 和 id 推导出来。

这张回执不会让过滤本身获得正当性。它要做的是让通知的形成过程可问责：说明信息在哪一关消失、在哪一关被拒绝、在哪一关会产生额外隐私成本。只有保存这条链，简洁的用户界面才不会冒充一份由所有参与方共同签署、实际上从未存在的统一解释。

来源