通过 ODoH 和 Numa 破解 DNS 隐私悖论

对于 Pi-hole、AdGuard Home 或标准转发解析器用户来说，DNS 隐私往往是一种权衡。你要么信任一个既能看到你的 IP 地址又能看到你访问的所有网站的单一运营商，要么切换到像 Unbound 这样的递归解析器，这会将你的 IP 地址暴露给链条中的每一个权威名称服务器。虽然 DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 加密了传输层，但它们并没有改变“谁能获知你的浏览习惯”这一根本现实。

Apple 的 iCloud Private Relay 试图通过将路径拆分为入口代理（看到 IP 但看不到请求）和出口代理（看到请求但看不到 IP）来解决这个问题。然而，这种解决方案被锁定在订阅服务、特定硬件和精选合作伙伴之后。对于自托管社区而言，一个无需账号要求或平台锁定且真正匿名的 DNS 选项一直难以实现——直到 ODoH 的采用。

理解 ODoH：Oblivious DNS over HTTPS

ODoH (RFC 9230) 是一种 IETF 协议，旨在通过在客户端和目标解析器之间引入中继器来使 DNS 查询匿名化。该过程通过一系列加密握手完成：

客户端： 使用目标解析器的 HPKE (Hybrid Public Key Encryption) 公钥对 DNS 查询进行加密。它还包含一个用于响应的对称密钥。
Numa 中继器： 接收请求。它能看到客户端的 IP 地址，但只能看到密文。它无法看到所询问的问题。
目标（例如 Cloudflare）： 使用其私钥解密问题。它能看到请求，但只能看到中继器的 IP 地址，而看不到原始客户端。
返回路径： 目标使用客户端提供的对称密钥对答案进行加密，并通过中继器发回，而中继器对内容保持盲目。

通过使用 HPKE (RFC 9180)，ODoH 确保了链条中的任何单一实体都无法同时拥有用户的身份（IP）和意图（DNS 查询）。

实现中继器：安全与架构

部署 ODoH 中继器并不像转发数据包那么简单；它需要特定的防护措施来防止基础设施被滥用。Numa 项目通过几个关键机制来实现这一点：

SSRF 加固

由于中继器会向请求 URL 中指定的目标建立出站连接，因此它是服务器端请求伪造 (SSRF) 的主要目标。为了缓解这一点，Numa 采用了正则严格的域名验证器，强制执行 RFC 1035 ASCII 标签，并明确禁止 IP 字面量、非 443 端口以及国际化域名 (IDNs)。

同一运营商检查

ODoH 的核心隐私保证依赖于中继器和目标由不同的组织运营。如果一个实体控制了两者，他们就可以将中继器的 IP 地址与目标的查询关联起来，从而使匿名性变成“表演”。Numa 实现了 eTLD+1 检查，默认拒绝中继器和目标共享相同组织域名的配置。

ODoH 的局限性

虽然 ODoH 显著提高了隐私，但它它并不是万能灵药。需要考虑几个操作和技术约束：

目标信任： ODoH 转移了信任，而不是消除它。目标解析器仍然能看到问题；保护措施仅仅是该问题无法归因于特定用户。
递归泄漏： 如果目标以递归模式运行，随后到根、TLD 和权威服务器的跳转通常是明文 UDP/TCP。ODoH 仅保护客户端到目标的这一段。
流量分析： 小型中继器容易受到时序攻击。如果中继器上只有一个活跃用户，目标可以根据传入请求的时间点来推断用户的身份。隐私程度随用户数量和填充流量 (padding traffic) 的规模而增加。
集中式密钥分发： 目前，客户端通过 HTTPS 从目标的 well-known 端点获取 HPKE 配置。这依赖于 WebPKI 系统；如果 PKI 被攻破，ODoH 配置的完整性就会面临风险。

扩展生态系统

直到最近，公共 ODoH 生态系统还非常薄弱。长期以来，dnscrypt-proxy 社区几乎完全依赖于单个公共中继器。通过在单个 Rust 二进制文件中提供客户端和中继器，Numa 旨在降低他人建立自己中继器的门槛。

该项目鼓励去中心化方法：独立的运营商越多，匿名集就越强大。对于想要实现这一点的人，Numa 提供了一个开箱即用的 Docker Compose 方案，用于在 Caddy 之后部署中继器以进行 TLS 终止。

结论

对于当今寻求匿名 DNS 的用户来说，路径现在变得更加触手可及。通过安装 Numa 并将模式设置为 odoh，用户可以将查询路由通过两个独立的组织，确保中继器和目标都不会拥有其数字足迹的完整视图。