加密 DNS 的钥匙难题：为什么再好的协议也可能用不上

你买了一把好锁，却发现钥匙拿不到——这正是现在很多人用加密 DNS 时的真实感受。

DNS-over-HTTPS（DoH）和 DNS-over-TLS（DoT）本来是用来保护域名查询的。它们把查询过程加密，让 ISP 或中间人看不到你在访问哪个网站。但问题很快就暴露了：加密再好，没法拿到密钥也白搭。

审查者不再硬破加密，而是直接卡钥匙

过去，封锁网站最直接的办法是把域名或 IP 拉黑。现在更聪明了——干脆不让你拿到加密用的密钥。

2021 年初，中国用户反馈 GitHub 访问时，加密 DNS 查询出现奇怪的波动：时通时断，连接没断，但查询经常失败。研究发现，防火墙已经升级成多层策略：

• 普通 DNS：继续投毒，返回假 IP
• DNS-over-TLS（853 端口）：直接封端口
• DNS-over-HTTPS（443 端口）：更隐蔽——只在你查询已知加密 DNS 提供商时，临时封 IP 几分钟，之后又放开。反复操作，用户基本就放弃了。

根本问题出在“密钥分发”

加密 DNS 的关键在于：浏览器必须先拿到公钥，才能开始加密查询。可公钥本身也要通过 DNS 拿回来。

这就形成了死循环：
想用加密 DNS，得先查 DNS；但查 DNS 的过程还没加密，就可能被拦截。

类似的情况也发生在 ECH（Encrypted Client Hello）上。浏览器想隐藏你访问的网站域名，需要先从 DNS 里取到 ECH 公钥。可如果 DNS 本身被卡，ECH 就永远走不出去。

对站长和开发者意味着什么

如果你在用 NameOcean 或管理全球域名，以下假设可能已经不成立：

1. DNS 记录全球都能访问
   某些地区可能根本连不上你的 DNS 服务器。

2. 加密协议能解决可见性问题
   加密本身是解决了，但密钥分发依然暴露在网络控制者面前。

3. 审查一定是彻底封锁
   现在更多是“制造摩擦”——不让你连不上，而是让你连得很卡、很烦，最后自己放弃。

目前大家在尝试的几种方向

• 去中心化密钥分发：用 DNSSEC 或区块链方式，让密钥更难被单点拦截
• 流量混淆：把加密 DNS 伪装成普通 HTTPS 流量，降低被识别的概率
• Anycast + 多地部署：把服务点铺开，增加封锁难度
• 应用内嵌入密钥：不完全依赖 DNS，在应用层直接分发必要信息

这些办法没有一个是完美的，都在性能、易用性和复杂度之间做权衡。

最后想说

隐私工具从来不是真空里的技术问题。它受制于网络结构、政治环境和对手策略。

当你设计域名系统、API 或用户服务时，要多想一步：如果有人控制了网络层，会怎么阻止用户拿到密钥？ 你的应对方案是什么？

加密 DNS 的“钥匙问题”还没彻底解决。未来的方案大概率会更分散、更复杂，也需要用户自己多留心。这不是技术做不到，而是现实世界本就如此。