摘要

  • 草案让解析器发送数据库运营方标识与事件标识，由应用用本地注册表副本展开地址并决定信任；解析器无权直接注入任意链接或公共文案。
  • 机制并不保证应用能看到详细 DNS 响应。发送、主机暴露、应用解析、策略接受、界面展示、用户点击与页面取回必须分别计量。

解析器返回了结构化过滤错误，也附上两个数据库条目。抓包证明字段完整抵达设备。浏览器却只显示“无法找到服务器”。

问题不在解析器，也不在数据库。操作系统的解析接口把详细响应压缩成了一个通用失败码。

这条缝隙决定了 draft-ietf-dnsop-filtering-transparency-00 能承诺什么。它试图让被法律命令或其他政策过滤的 DNS 名称不再伪装成普通技术故障，但它明确承认：应用架构与主机接口可能根本不交付所需信息。

第 00 版发布于 2026 年 8 月 1 日，将于 2027 年 2 月 2 日到期，是 DNSOP 工作组的活跃 Standards Track Internet-Draft。它不是 RFC、已建立的 IANA 注册表、浏览器规则或部署统计；其 fdbs 字段还依赖同样处于草案状态的结构化 DNS 错误规范。

两个标识只构成一条候选路径

DNS Filtering Database Entry 包含 db 与 id。前者指向过滤事件数据库运营方，后者指向一个事件。fdbs 列表可以装入多个条目，但它们必须声称关联同一个底层事件。

草案没有让解析器直接给出 URL。原因是解析器常由当前网络自动配置，DNS 响应也可能来自不可信方。如果咖啡店网络能够把任意链接写进浏览器的错误页，它就获得了新的钓鱼入口。

应用保留拟议注册表的本地副本。注册表把运营方 ID 映射到一级或二级 URI 模板；应用代入事件 ID 后得到地址，再按本地策略决定是否呈现。

这条路径把权力拆开：解析器选择引用哪些数据库，注册表协调模板，应用选择信任哪些运营方，用户决定是否发出后续请求。任何一步都不能替其他步骤作决定。

主机接口是看不见的闸门

解析器可能完全遵守草案，设备也可能收到完整报文，但应用仍然无法读取 EDNS 细节。不同操作系统、解析库、沙箱与代理层暴露的信息不同。

因此，“解析器已发送”的遥测不能成为“用户已获知”的证明。浏览器编译进了 fdbs 支持，也不等于运行环境会把字段交给它。数据库看不到访问量，更不能倒推出解析器没有引用它。

完整链条至少包括：解析器选定条目、DNS 响应抵达、主机保存并暴露结构化数据、应用成功解析、本地注册表识别运营方、策略接受、界面展示、用户激活、页面取回、内容可理解。

每个阶段都有自己的分母。把首尾相除会把中间损失伪装成用户冷漠或解析器不支持。真正的透明度报告应公开每一道闸门。

注册表协调地址，不认证事件

拟议注册表以运营方 ID 为键，记录数据库名称、联系方式与解析模板。登记政策是先到先得，IANA 可以拒绝欺骗性或虚假申请。

这不是资质认证。登记不会验证数据库的证据方法、法律能力、纠错机制、保存期限或政治独立性。应用仍须维护自己的信任集合。

应用还必须保存本地副本，不能每次使用都实时查询 IANA。这样减少中央观察点，却带来版本差异。运营方可以更新模板，而客户端可能数月后才吸收。

要复现读者看到的链接，必须记录注册表快照与更新时间。只查看今天的 IANA 状态可能会重建出另一条路径。

页面能打开仍不是因果证明

草案明确不认证应用遭遇的过滤事件是否真的对应所呈现信息。控制解析器的攻击者可以宣称过滤发生，哪怕事实并非如此。

攻击者需要重用一个能展开并成功访问的 db/id 组合。这增加成本，却不是密码学证明。真实数据库里的真实页面可以被错误地绑定到另一条查询。

解析器提出相关性，注册表提供路由，数据库发布记录。HTTP 200 只证明资源可达。它不证明该资源造成这次 DNS 结果，也不证明法律命令存在。

产品文案应区分“解析器报告”“注册表识别”“页面已取回”与“事件已认证”。最后一种状态超出草案能力。

点击说明会制造第二次暴露

访问事件地址可能向数据库运营方披露用户 IP，以及用户尝试解析了哪个受过滤或审查的域名。在某些司法辖区，这个组合本身就有风险。

即便用户信任数据库，路径观察者仍可能从目标、时间、URL 或唯一标识推断事件。隐私代理能够遮蔽直接来源，但代理会成为新的日志与控制点。

草案因此要求：没有隐私保护机制时，应用不得在用户明确动作之前自动取回事件页面。

“自动”不只指打开标签页。链接预览、安全扫描、信誉检查、预连接、元数据展开与截图服务都会在无可见页面时发出请求。界面没展示不等于隐私边界没跨越。

记录必须把链接构造、展示、点击、代理选择、出站、重定向与响应拆开。一个“说明已显示”事件无法证明点击发生在请求之前。

唯一事件 ID 可以成为关联句柄

id 可以专用于单次请求，也可以复用。灵活性方便数据库组织内容，也让基数与生命周期成为安全属性。

解析器与数据库若串通，可以为每次 DNS 事件生成唯一 token，再观察哪个 token 被访问。一家机构同时经营两端也有同样能力。解释链接于是把 DNS 意图与后续网页请求连接起来。

用户选择可信数据库能降低风险，却不能证明对方没有使用唯一 ID。应用需要了解 ID 是按事件、域名、网络、客户端还是查询生成，多久过期，访问日志保存多久。

代理只能改变看到源地址的主体，不能自动抹去 token。如果代理保存时间和目标，关联只是迁移了位置。

多个数据库不会自动产生真相

列表允许同一事件关联多个数据库，提高应用至少认识一个运营方的概率。但不同记录可能在日期、法律依据、受影响名称或请求主体上冲突。

“同一底层事件”首先是解析器的声明，不是独立证明。页面数量也不能变成真实性投票。

应用可以展示分歧、根据明确策略排序，或拒绝合成。它不应把多个来源揉成无来源的一段权威说明。透明度的对象正是“谁说了什么”。

沉默有多种含义

没有界面提示，可能是主机没暴露字段、应用不支持、注册表副本过旧、运营方未获信任或策略选择隐藏。没有页面访问，可能是用户拒绝、代理失败、模板失效或自动取回被正确禁止。

这些未知状态不能被一个成功率吞掉。控制点不同，修复责任也不同。解析器运营方无法修复浏览器 API，数据库运营方无法替用户同意披露。

治理需要逐段收据：谁发出、谁传递、谁筛选、谁展示、谁点击、谁取回。只有这样，问题才不会被推给可见但无控制权的一端。

透明度不能靠制造确定性

草案最重要的设计不是 fdbs 名称，而是对任意链接注入的克制。解析器只能提供有限引用，应用持有信任决定，用户保留是否访问的选择。

实现若把所有登记运营方自动加入白名单、预取全部页面、隐藏注册表版本或把页面可达标成“已验证”，就会重新集中这些权力。

DNS 过滤说明可以把政策干预与普通故障区分开。它不能凭两个标识完成事件认证，也不能以后台访问为代价替用户选择。真正的透明度必须同时解释信息来自哪里，以及为什么有些后续动作没有发生。

来源