加载失败
ODoH（Oblivious DoH，一种把 DNS 查询拆成 relay 和 target 两层的隐私协议）试图让中继只看到客户端 IP，而解析器只看到被查询的域名，从而避免单点同时掌握两类信息。这个帖子是在宣布第二个 public ODoH relay 上线，代码基于 Cloudflare 的 odoh-rs/HPKE 实现，部署在 VPS 上并用 systemd 与 Caddy 提供服务。评论区把它和 ECH（Encrypted Client Hello，TLS 中加密 ClientHello 的扩展）、SNI（Server Name Indication，握手里暴露域名的字段）、Tor、DNSSEC 等话题联系起来，讨论 DNS 隐私到底能做到哪一步。争论核心不是“要不要加密 DNS”，而是“在公共解析器、ISP、以及自建递归解析器之间，如何平衡匿名性、可用性和信任成本”。
有人质疑在 ECH 采纳率很低的情况下，ODoH 的卖点并不明显，因为 TLS 里的 SNI 仍可能把你访问的站点名暴露出去。回应则强调 ODoH 解决的是另一层问题：它把 DNS 查询内容从单一观察者手里拆开，让 relay 和 target resolver 各自只看到一半。也有人指出，哪怕只能修补一个泄漏点，也比什么都不做更有意义，因为隐私防护往往是分层叠加而不是一次到位。讨论里还提到，TLS handshake 本身的泄漏是另一个需要单独处理的议题。
当有人问“真正匿名的 DNS”是否可能时，回复普遍认为 ODoH 只是接近目标的一步，不足以独自消除关联风险。要降低 relay 与 resolver 串通的可能，通常需要像 Tor 那样再叠加多跳加密路径。另一个必须解决的问题是响应完整性，否则恶意解析器可以把用户导向自己的 IP 并透明代理请求。DNSSEC 被点名为现有方案，但也被批评成很 90s 的设计，能用却显得过时；另有人补充 Cloudflare 的 1.1.1.1 可经由 Tor 使用，但延迟和客户端指纹问题仍在。
一些人把 ODoH 的价值理解为：可以继续用 Cloudflare、DNS4EU 这类速度快的公共 DNS，但不用把全部查询直接交给单一公司。反方则提醒，普通 ISP 也不是什么天然安全的选项，因为递归 nameserver 可能被出售数据，链路里甚至可能存在端口 53 的窃听。与此同时，自建 recursive nameserver / pi-hole 虽然更可控，却会让自己的流量特征更明显，反而降低匿名性。最后形成的共识更像是：公共解析器要有足够多用户才有匿名集合，自建方案则是在控制权和隐身性之间交换。
有评论把 ODoH 的信任模型讲得很直接：relay 只能看到客户端 IP 和 ciphertext，target resolver 只能看到域名和 relay 的 IP，单方拿不到完整的“谁在查什么”。当有人担心 relay 和 target 由同一提供方运营时，回复指出查询一开始就是用目标解析器的公钥加密的，relay 不能随意改投别的目标，否则目标端根本解不开。项目里还加入了 eTLD+1 级别的同运营方检查，默认拒绝 relay 和 target 同属一个组织。这个设计并不保证绝对匿名，但至少把“单点全知”拆开了。
发帖者给出的不是概念介绍，而是一个可运行的 public relay：它跑在 VPS 上，TLS 由 Caddy 处理，进程作为 systemd unit 管理。安全上做了 SSRF hardening，比如严格的 hostname regex 和禁止 IP literals，避免被当成通用转发器。加密部分使用 Cloudflare 的 odoh-rs / HPKE 实现，仓库里也给出了安装与配置方式。整体看，这说明 ODoH relay 已经从协议讨论走到了实际部署层面。
ODoH: Oblivious DoH，把 DNS 查询拆成 relay 和 target 两层，分离客户端 IP 与查询内容。
ECH: Encrypted Client Hello，TLS 扩展，用来加密 ClientHello，减少 SNI 泄漏。
SNI: Server Name Indication，TLS 握手中会暴露目标域名的字段。
Tor: 匿名网络，通过多跳中继隐藏来源和目的。
DNSSEC: DNS 安全扩展，用签名验证 DNS 响应未被篡改。
recursive nameserver: 递归 DNS 解析器，代表客户端向其他 DNS 层级继续查询。
HPKE: Hybrid Public Key Encryption，ODoH 等协议用的公钥混合加密方案。
eTLD+1: effective top-level domain plus one，用来判断注册域名层面的同源关系。