DNS 安全：DoH 与 DoT

域名系统将人类可读的域名转换为 IP 地址。标准 DNS 查询使用 UDP 的 53 端口，并且完全未加密。您的设备查询的每个域名都会对路由器、ISP 以及任何能够监测网络路径的人可见。这意味着，即使您访问的每个网站都使用 HTTPS，您的浏览活动仍然会暴露。

互联网服务提供商（ISP）通常会记录所有客户的 DNS 查询，用于网络监测，也用于遵守许多司法管辖区的数据保留法律。这些记录构成了每个访问过的网站、每次访问时间以及访问频率的详细档案。ISP 曾将这些数据出售给广告商，也曾仅凭 DNS 记录响应政府对用户浏览历史的请求。

能够截获或重定向 DNS 流量的攻击者可以篡改响应，将用户引向恶意服务器。DNS 劫持可能发生在路由器层面（路由器遭到入侵时），也可能通过提供攻击者控制的 DNS 解析器地址的恶意 DHCP 服务器发生，或由 ISP 层面的重定向引起。用户输入合法域名后，可能会在毫无察觉的情况下被引导至钓鱼网站。

设备加入网络时，会通过 DHCP 请求配置；DHCP 会提供 IP 地址、网关和 DNS 服务器。位于本地网络中的攻击者如果运行恶意 DHCP 服务器，就可以比合法服务器更快地响应，并提供自己的 DNS 服务器地址。受害者后续发出的所有 DNS 查询都会发送到攻击者的解析器，使攻击者能够在整个会话期间监视查询并篡改响应。

2008 年，研究人员 Dan Kaminsky 披露了 DNS 中的一个严重漏洞。攻击者可以发送数千个带有随机事务标识符的伪造 DNS 响应，在解析器收到合法响应之前，利用统计概率破坏其缓存。这被称为生日攻击式缓存投毒。缓存遭到破坏后，该解析器的所有用户都会被重定向到攻击者控制的 IP 地址。

DNSSEC（DNS 安全扩展）通过为 DNS 记录添加密码学签名，解决缓存投毒和响应伪造问题。每个 DNS 区域都会使用私钥为其记录签名；解析器则使用发布在 DNSKEY 记录中的对应公钥验证签名。伪造或修改过的响应会无法通过签名验证，并被拒绝。DNSSEC 建立了从 DNS 根区域一直延伸到单个域名记录的信任链。

基于 TLS 的 DNS（DoT）会在 853 端口上，将 DNS 查询封装在标准 TLS 连接中。解析器和客户端会先完成 TLS 握手，然后才发送 DNS 查询，从而加密查询（包括域名）和响应。DoT 可以防止 ISP 和网络观察者进行被动监视。由于使用专用端口 853，防火墙可以识别 DoT；某些网络会利用这一点阻止 DoT。

基于 HTTPS 的 DNS（DoH）会将 DNS 查询编码为 443 端口上的 HTTPS 请求，该端口也用于所有网页流量。由于 DoH 流量与普通 HTTPS 流量无法区分，防火墙很难在不同时阻止所有 HTTPS 流量的情况下阻止它。Firefox、Chrome 和 Windows 11 原生支持 DoH，Cloudflare（1.1.1.1）和 Google（8.8.8.8）等提供商也提供 DoH 端点。

使用 DoH 或 DoT 时，您的 DNS 查询会在设备与 DNS 解析器之间传输的过程中进行加密。ISP 无法读取或记录您查询的具体域名。恶意 DHCP 攻击无法注入会读取您流量的解析器，因为合法解析器的地址已被硬编码。网络攻击者也无法通过被动截获来实施 DNS 劫持。不过，DNS 解析器自身仍然可以看到您的所有查询。

ISP 曾游说反对强制部署 DoH，因为这会将 DNS 可见性从 ISP 转移到少数大型科技公司的解析器。UK 的 ISP 向议会投诉，称 DoH 会妨碍家长控制过滤。网络管理员认为，集中式 DoH 会破坏企业 DNS 策略和分视图 DNS 配置。IETF 已在 RFC 8484 中将 DoH 标准化，但部署政策仍存在争议。

DNSSEC 要求域名所有者为其区域签名，并要求解析器执行验证。密钥轮换（在不中断服务的情况下更换签名密钥）十分复杂，并且已经导致主要顶级域发生服务中断。.com 和 .net 顶级域支持 DNSSEC，但只有少数单独域名完成了签名。DNSSEC 不会加密查询；只有 DoH 和 DoT 能够提供查询隐私。

UDP 53 端口上的标准 DNS 未加密，并且会被 ISP 记录。DNS 劫持和 Kaminsky 缓存投毒攻击利用了这一弱点。DNSSEC 添加密码学签名以防止响应伪造，但不会加密查询。853 端口上的 DoT 和 443 端口上的 DoH 会加密传输中的 DNS 查询。DoH 比 DoT 更难被阻止。加密 DNS 会将信任从 ISP 转移到解析器运营者，但并不会消除信任要求。