摘要

  • 一次经过身份认证的加密 DNS 会话，只能成为边界清楚的传输凭据；它不能证明递归解析器如何留存、关联、共享、过滤数据，或把什么信息送往上游。
  • RFC 8932 提出的递归解析器运营者隐私声明（RPS）让这些做法可以横向比较，但可靠的隐私承诺仍需为传输、解析处理、存储与访问、对外披露分别保存有时效的证据。

用户在系统设置里选定一个加密 DNS 服务，设备与解析器建立 TLS、HTTPS 或 QUIC 连接。本地网络上的被动观察者不再能轻易读到每一个域名问题，客户端也可以确认自己连接的是谁。对公共 Wi-Fi、接入网络乃至企业边界而言，这不是装饰性的升级。

然而，加密连接到了递归解析器就会终止。解析器必须解开问题，才能查缓存、验证答案，或者继续向别的解析器和权威服务器提问。运营者原则上仍能看到查询内容和用户的传输标识，也能决定记哪些字段、留多久、谁可以访问、是否跨会话关联、是否改写答案，以及下一跳携带多少用户信息。

锁形图标对这些决定保持沉默。

这正是 RFC 8932《DNS 隐私服务运营者建议》最值得保留的边界。该文件于 2020 年 10 月以 BCP 232 发布，作者是 Sara Dickinson、Benno Overeinder、Roland van Rijswijk-Deij 和 Allison Mankin。IETF Datatracker 在 Dickinson 的个人页中列出八份 RFC，其中包括 RFC 8932 与 DNS over QUIC 的 RFC 9250，并记录她担任隐私增强与评估研究组主席。RIPE Labs 则将她介绍为 Sinodun IT 的联合创办人。这里的归属应当保持精确：她参与的是集体工作，不是独自发明加密 DNS，也不控制任何被讨论的解析服务。

RFC 8932 一方面为提供加密 DNS 的运营者提出实践建议，另一方面给出递归解析器运营者隐私声明——Recursive operator Privacy Statement，简称 RPS——的共同框架。RPS 不是统一的隐私政策，更不是一张自动生效的合规证书。它的作用，是让运营者按相近顺序说明承诺与现行做法，让读者能比较“声称具备的属性”和“可以测量的属性”。

要理解这项设计，可以把一次解析拆成四张凭据。

第一张是客户端到解析器的传输凭据。它应记录解析器端点、认证名称、所用协议、证书结果、TLS 或 QUIC 版本、填充设置、可用性，以及失败后是否退回明文。RFC 8310 讨论 DNS over TLS 的使用配置，RFC 8484 规定 DNS over HTTPS，RFC 9250 后来规定专用 QUIC 连接上的 DNS。它们保护的都是“去往解析器的这段路”，而不是运营者解密之后是否忘掉查询。

传输加密也不能替 DNSSEC 作证。RFC 8932 明确指出，两者解决不同问题。对于不自行验证 DNSSEC 的客户端，经过认证和加密的连接，并不能证明解析器确实完成了 DNSSEC 验证，也不能证明返回数据已经通过 DNSSEC 认证。客户端可能只是相信解析器设置的 AD 位。拿 TLS 证书去证明 DNSSEC，等于让一张车票证明货物验收。

第二张是解析服务内部的处理凭据。解析器采用了什么验证模式？某项安全策略是否改写了答案？缓存如何参与？异常条款是否触发？服务是否通过 IP 地址、会话恢复标识、HTTP 特征、TLS 指纹或反复出现的查询模式，把多个连接重新关联到同一个用户？RFC 9076 还提醒，即使客户端一侧的 DNS 已经加密，流量仍有可能与递归解析器向外发出的明文查询相关联。

固定使用一个加密解析器因此具有两面性。用户更清楚谁能看到查询，不必在不同网络中把隐私交给未知的默认服务；与此同时，同一运营者也更容易在用户跨网络移动时持续识别其行为。这不是否定加密，而是说明“减少沿途观察者”和“减少目的端关联”是两项控制。

答案过滤也属于处理凭据。RFC 8932 要求 RPS 说明是否为网络安全、具有约束力的法律命令、自愿降低法律风险、商业原因或其他原因过滤、编辑或改变回复，并说明过滤清单如何建立、由哪些第三方提供。于是，“安全 DNS”完全可能同时意味着通道保密与答案被修改。读者需要分别知道这两个事实。

第三张是存储与访问凭据。RFC 8932 建议尽量减少、甚至避免留存；确需保留时，应当加密，并在可行处聚合、假名化或匿名化。流量日志的保存期应限于维持服务和履行适用监管要求所必需的时间，访问权也应仅交给承担相应运营职责的人员。

建议写得再严谨，仍不能跳过执行证据。隐私政策写“保存七天”，只能证明一句公开承诺；删除作业的完成记录，才能说明某一轮数据已按时处理。角色定义写“仅运维人员”，不能替代实际访问日志。磁盘加密状态也不能证明数据没有被导出。尤其不能把假名化随口称作匿名化：稳定替代标识仍可能让长期行为被串联，当映射或方法可得时，还可能恢复真实身份。

第四张是离开解析器的数据凭据。递归解析通常需要继续向其他递归服务或权威服务器发问。RFC 8932 建议采用 QNAME 最小化，让每一级服务器只看到完成当前委派所需的名称部分；RFC 9156 后来更新了这套做法。文件还建议尽量不发送 EDNS Client Subnet（ECS）；如果业务确需 ECS，就使用运营上可行的最短前缀，并公开真实策略。

这是一条容易被第一段加密遮住的边界。一次外部测试可以观察某个名称是否按层最小化、某次查询是否没有 ECS。这是有价值的现场证据，但它有时间、观察点和测试样本，不能自动覆盖所有域名、所有转发器和所有策略分支，更看不到查询落盘后是否被交给第三方。

因此，RFC 8932 为 RPS 安排的内容远多于一句“我们重视隐私”。政策部分应说明 IP 地址是否按个人数据处理；收集、保存、共享、出售或出租哪些数据；采用何种最小化方法和传输条件；有哪些例外；有哪些关联实体与资金来源；是否与其他个人信息做关联；是否过滤答案。实践部分则说明当前客户端端点的传输与认证能力、上游行为、偏离政策的情形、支持渠道和相关数据处理信息。

一份好的 RPS 应该像证据索引，而不是品牌宣言。“我们采用 QNAME 最小化”可以指向配置记录和独立探测；保存期限可以指向生命周期规则与删除结果；访问限制可以指向角色策略和经审计的访问事件；第三方共享声明可以列出接收者、目的、字段、条款与到期日。透明度报告和有明确范围的第三方审计，还能继续检查这些连接。

但索引不能冒充事实本身。审计有时间段、样本与范围，探测有观察位置，透明度报告取决于撰写者可以看到什么，RPS 也可能落后于线上配置。正确结论不是“隐私无法验证”，而是每一种承诺都应找到合适的见证，同时注明证据不能覆盖什么。

Dickinson 与共同作者提供的持久价值，正是把这些隐蔽决定变成可以提问的栏目。评估解析器隐私时，问题不应止于“管道是否加密”，还应继续追问：查询抵达后谁有权作出哪些决定，什么记录会留下，这些承诺多久能够重新核验？

来源