DNS 查询为什么要加密？

在浏览器地址栏输入一个网址，按下回车。屏幕上看起来只发生了一件事：网页开始加载。实际上，在浏览器连上网站之前，它还要先完成一次很短、很基础的网络操作。它得把域名转换成服务器能够接受的 IP 地址。

比如，你输入的是 www.example.com。浏览器不能拿着这串文字直接建立网络连接，因为互联网的路由设备并不靠域名转发数据。浏览器需要先知道这个网站的服务器在哪里，或者至少知道下一步该找哪个服务器。这项工作由 DNS 完成。DNS 会返回一个或多个记录，其中最常见的是 IP 地址。浏览器拿到地址后，才会发起 HTTPS 连接，下载页面、图片、脚本和其他内容。

图 1：浏览器并不是拿到域名就直接打开网页。它通常要先完成 DNS 查询，再连接网站服务器。

大多数时候，这一步快到人感觉不到，所以 DNS 很少进入普通用户的视野。可只要上网，它几乎都会出现：打开新闻网站、启动手机应用、点开邮件里的链接、连接游戏服务器，设备往往都要先查一次域名。

麻烦在于，传统 DNS 诞生得很早。那时还没有今天这样的公共 Wi-Fi、移动网络、广告追踪和大规模网络监测，设计目标只是尽快把域名换成地址，并不打算把用户问了什么藏起来。于是直到现在，许多 DNS 查询仍会通过 UDP 或 TCP 的 53 端口明文发出。网页本身也许已经使用 HTTPS，正文和密码通常不会直接暴露；但设备刚刚查询过哪个域名，路径上的人仍可能看得见。

这就是 DNS over HTTPS，也就是 DoH，出现的原因。

传统 DNS 暴露的到底是什么

先把范围说清楚。传统 DNS 并不意味着“任何人都能看到你所有的上网内容”。网页使用 HTTPS 时，网络旁观者一般不能直接读取网页里的文字、表单内容或账号密码。DNS 暴露的是另一个层面：在真正连接网站之前，设备向解析器询问的域名。

如果你使用酒店、机场、咖啡馆或其他公共网络，这个网络本身通常会参与数据转发。传统 DNS 查询从设备发出去后，附近的网络设备、接入网络或路径上的中间设备有机会直接看到查询的域名。它们未必都在恶意监控，但技术上确实有这个条件。有些网络还会利用 DNS 做跳转、广告注入、页面劫持，或者把不存在的域名导向自己的页面。

DNS 查询之所以敏感，是因为域名本身常常很有信息量。查询一个银行、医院、学校、求职平台或特定云服务的域名，不等于泄露你在那个网站里做了什么，却能透露你可能正在接触哪类服务。把这种信息长期暴露给所有经过的网络，并不是一个理想状态。

DoH 没有重新发明 DNS。它只是改变了 DNS 查询离开设备时的包装方式。IETF 在 RFC 8484 中定义了这个协议：一对 DNS 查询和响应被放进一次 HTTP 交换里，使用 HTTPS 的加密和身份认证机制传输。

DoH 做的事，比名字听起来简单

“DNS over HTTPS”这个名字容易让人误会，以为 DNS 变成了一个网页服务。不是这样。DNS 还是 DNS，查询的内容还是标准 DNS 消息。变化在于，设备不再把这条消息直接以传统 DNS 的方式发送出去，而是把它放进 HTTPS 请求里，交给支持 DoH 的解析器处理。

这和你平常打开网页时使用的 HTTPS 是同一类安全连接。设备会验证对方的证书，并对传输内容加密。于是，设备到 DoH 解析器之间的网络路径，不再能像以前那样从 DNS 报文里直接读出域名。Cloudflare 的 DoH 文档 也把这种效果概括为：把 DNS 查询包进常规 HTTPS 请求，降低路径上的伪造和篡改风险。

图 2：传统 DNS 中，网络设备可能直接读到查询域名。DoH 将查询放进 HTTPS 连接后，网络仍能观察到连接存在，但不能直接读取其中的 DNS 内容。DoH 解析器仍需要读取查询，才能给出答案。

图里的最后一句很重要：解析器仍然要读到查询。因为它不读，就无法告诉你服务器在哪里。DoH 不是把 DNS 变成一场谁也看不见的魔术，而是缩小了能直接看到查询内容的范围。

过去，用户往往默认使用接入网络提供的解析器。打开 DoH 后，浏览器、操作系统或路由器可能会使用另一家明确指定的加密解析器。于是，当前 Wi-Fi 或路径上的中间设备更难直接查看查询内容，但你也把更多信任交给了这家解析器。它知道你问了什么，并且通常还能看到连接来自哪个 IP 地址或代理地址。

这不是 DoH 的漏洞，而是 DNS 工作方式的现实。任何递归解析器都必须处理查询。真正需要问的问题是：你愿意让谁处理，你如何判断它的隐私承诺是否可信，它会保留哪些数据，多久后删除。

加密以后，谁还能知道什么

讨论 DoH 时，最容易出现的两种极端说法都不准确。

第一种说法是：“DoH 没用，因为解析器还是能看见。” 这忽略了路径上的直接窥探本来就是一个独立问题。公共网络、接入网络与 DNS 解析器不是同一个角色。DoH 让前者更难直接读取查询内容，本身就有明确的隐私和安全意义。

另一种说法是：“打开 DoH 后，没有人知道我访问过什么。” 这又走得太远了。DoH 保护的是 DNS 查询从设备到解析器这一段。它不隐藏设备与网站之间的其他连接，也不会清除浏览器账号、Cookie、指纹或 IP 地址带来的识别能力。即使只看 DNS，网络也仍可能看到连接时间、流量大小和目标地址等元数据。

安全研究还发现，单靠加密 DNS 内容，不足以抹去所有流量特征。NDSS 2020 的一项研究表明，在特定攻击模型下，观察者能利用数据包大小和时序来推测用户查询过的部分域名；研究测试的标准化填充方式也没有彻底抵御这种分析。这不是说 DoH 没有价值，而是在提醒我们：加密内容与消除通信痕迹，是两件不同的事。

所以，DoH 的准确定位应该是：它保护 DNS 查询内容不被网络路径上的旁观者轻易直接读取或修改，但不提供完整匿名性，也不让递归解析器失去对查询的可见性。

不同解析器对用户数据的处理方式也不一样。Cloudflare、Google Public DNS 与 Quad9 都公开了隐私政策，但对 IP 地址、查询日志、保留期限和聚合数据的描述各有差异。这解释了为什么“支持 DoH”不能自动推出“最重视隐私”。协议是传输方式，数据政策是服务商选择。两者都要看。

DNSSEC、DoH 和 VPN，不是在做同一件事

DNS 领域里有很多缩写，最容易混淆的是 DoH、DNSSEC 和 VPN。它们都和安全有关，但保护的位置不同。

DNSSEC 解决的是“答案是真是假”。DNSSEC 会给 DNS 数据加上可验证的签名。支持验证的解析器可以检查一个 DNS 回答是否来自正确的信任链、是否在传输或缓存过程中被替换。DNSSEC 不隐藏查询内容。IETF 对 DNSSEC 的定义说得很直白：它提供来源认证和完整性保护，但不提供保密性。

DoH 解决的是“提问过程会不会被直接看到”。它让设备和 DNS 解析器之间的查询通过 HTTPS 传输。DoH 不替 DNS 回答做来源认证，也不会凭空让一个不可信的解析器变成可信的解析器。

VPN 的范围又更大一些。VPN 通常会把设备到 VPN 服务器之间的多类网络流量放进加密隧道，DNS 只是其中的一部分。VPN 也不是万能的，它把信任从接入网络转移给 VPN 服务商。三个技术可以配合使用，但没有一个能替代另外两个。

图 3：DoH 保护设备到解析器之间的 DNS 查询传输。DNSSEC 用于验证 DNS 数据的来源和完整性。VPN 通常覆盖更广的网络流量，但会把信任交给 VPN 服务商。

如果把它们压缩成三句话：DoH 让别人不容易看见你的 DNS 提问；DNSSEC 帮你判断收到的 DNS 回答有没有被伪造；VPN 让设备到 VPN 服务器之间的更多网络流量进入加密通道。弄清这一点，就不容易被“某一项技术解决所有隐私问题”的宣传带偏。

使用 DoH 会不会变慢

没有固定答案。

DoH 需要建立 HTTPS 连接，第一次连接时会有握手成本。传统 DNS 的单次请求很轻，直接把两者放在一起测速，DoH 有时确实可能显得慢一点。但浏览器和操作系统不会每查一个域名都从零开始。它们可以复用已经建立的连接，也会缓存 DNS 结果。RFC 8484 本身就讨论了 HTTP 缓存和减少重复查询的方式。

因此，真正影响体验的往往不是“DoH 这三个字”，而是解析器离你多远、网络是否稳定、设备有没有复用连接、当地接入网络的质量如何，以及所选解析器的节点布局。IMC 2021 的全球测量研究发现，DoH 的性能会随地区与网络条件明显变化。

还有一个常被忽略的细节：失败时怎么办。为了避免用户因为 DoH 服务暂时不可用而打不开网页，一些浏览器默认允许回退到普通 DNS。Chrome 的公开说明提到，如果 DoH 连接出现问题，浏览器会默认回退到用户当前服务商的常规 DNS，并周期性重试。Firefox 也区分“优先使用加密解析器，失败时回退”和“只使用加密解析器”的不同模式。

回退会提高可用性，却也意味着加密连接故障时，DNS 查询可能重新走传统路径。对于普通用户，这通常是体验和隐私之间的取舍。对有更严格隐私要求的人，回退策略是设置中值得认真看的部分，而不是一个可以忽略的小开关。

为什么学校和公司对 DoH 的态度更复杂

在家庭、学校和企业网络里，DNS 经常不只是“帮设备找地址”。它还被用来拦截钓鱼网站、恶意域名、不适宜内容，或者把内部服务的域名解析到公司自己的服务器。很多安全和管理工具都把 DNS 当作一个控制点。

如果浏览器或应用绕过组织指定的解析器，直接把查询发给外部公共 DoH 服务，原先依赖 DNS 的过滤、告警和审计可能就失去作用。于是，DoH 在这类环境里会带来真实的运维问题。

但解决办法不一定是回到明文 DNS。更合理的路径是让组织自己部署或指定加密 DNS 解析器，再通过设备管理、浏览器策略和系统设置控制解析路径。IETF 的后续标准已经定义了相应机制。DDR 允许客户端发现由同一实体或合作实体运行的加密解析器；DNR 则允许网络通过 DHCP 或 IPv6 路由器公告，向设备提供经过认证的 DoH、DoT 或 DoQ 解析器配置。

这意味着问题不该被说成“DoH 让网络失去控制”。更准确的说法是：DoH 迫使网络把原本建立在明文 DNS 上的管理方式，迁移到设备策略、受管理解析器和更明确的安全边界上。

普通人需要开启 DoH 吗

如果你使用个人手机或电脑，并且经常连接公共 Wi-Fi，开启系统或浏览器提供的“安全 DNS”或“加密 DNS”功能通常是合理的。它不能把你变成匿名用户，但可以减少传统 DNS 查询被附近网络直接读取的机会。

开启前不需要把所有协议文档看完。你只要知道两件事。第一，设备准备把 DNS 查询交给哪家解析器。第二，如果加密连接失败，设备会不会退回普通 DNS。前者决定你把信任交给谁，后者决定保护在故障时是否还会保留。

如果设备属于公司、学校，或者家庭网络依赖 DNS 过滤来阻止恶意网站和不适宜内容，不要在不了解影响的情况下自行修改。这不是因为 DoH 不安全，而是因为你可能绕开了一个正在承担其他任务的安全机制。

DoH 的价值并不神秘。浏览器访问一个网站之前，通常先要完成 DNS 查询。过去，这一步常常以明文发出。DoH 做的事，是把设备到解析器之间的这一步放进 HTTPS 保护中。它解决不了所有隐私问题，却补上了互联网长期存在的一个空缺。