了解 DNS 的作用
DNS（域名系统）常被比喻为互联网的"电话簿"。当你在浏览器中输入"kakunin-san.com"时，DNS 服务器会将该域名转换为对应的 IP 地址，并促成与目标服务器的连接。
这个域名解析过程在你每次打开网页时都在后台默默运行。默认情况下，DNS 请求会发送到你的 ISP 提供的 DNS 服务器，这意味着你的 ISP 可以通过这些 DNS 请求准确地看到你正在尝试访问哪些网站。
了解 DNS 的工作原理是保护隐私的第一步。在 IP 确认酱首页，你可以查看当前连接使用的 DNS 服务器。先来确认一下你的网络环境依赖的是哪个 DNS 服务器吧。
什么是 DNS 泄漏？
DNS 泄漏是指在使用 VPN 或代理的情况下，DNS 请求绕过 VPN 隧道，直接到达 ISP 的 DNS 服务器的现象。
使用 VPN 的主要目的之一是防止 ISP 和其他第三方看到你的浏览记录。然而，当 DNS 泄漏发生时，即使你的流量内容是加密的，你访问了哪些网站的信息仍然会暴露给 ISP。这是一个从根本上削弱 VPN 保护能力的严重问题。
一个常见的误解是，连接 VPN 就会自动保护你的 DNS 查询。实际上，根据 VPN 的实现方式和操作系统设置，DNS 请求可能仍然在 VPN 隧道之外传输。不要仅仅因为使用了 VPN 就认为自己是安全的，请定期检查是否存在 DNS 泄漏。
DNS 泄漏为什么会发生？
操作系统 DNS 配置冲突
即使连接了 VPN，操作系统可能仍保留原始的 DNS 设置。这在 Windows 上尤为常见，VPN 连接建立时 DNS 设置有时无法正确切换。Windows 的智能多宿主名称解析功能可能会将 DNS 查询并行发送到 VPN 隧道外的服务器，加剧了这一问题。
IPv6 流量泄漏
如果 VPN 只隧道化 IPv4 流量而不处理 IPv6，通过 IPv6 发送的 DNS 请求可能会泄漏到 VPN 隧道之外。随着 IPv6 的普及，这个问题正变得越来越严重。
WebRTC 泄漏
浏览器的 WebRTC 功能可以绕过 VPN，将本地 IP 地址或 DNS 信息暴露给外部。这个问题在我们的 WebRTC 泄漏指南中有详细介绍。
分流隧道配置错误
部分 VPN 提供"分流隧道"功能，只将特定流量通过 VPN 路由。如果配置不当，DNS 请求可能会在 VPN 隧道之外传输。
网络切换时的临时泄漏
从 Wi-Fi 切换到移动数据，或在不同 Wi-Fi 网络之间切换时，VPN 连接可能会短暂中断，在此期间 DNS 请求可能会到达 ISP 的 DNS 服务器。配置防火墙阻止 VPN 外的 DNS 流量有助于缓解这一问题。
DNS 泄漏带来的风险
- ISP 可以看到你的浏览记录
- 未加密的 DNS 请求可能被网络上的第三方截获
- VPN 的有效性大幅降低
- 绕过地理限制的尝试可能失败
- 更容易受到 DNS 劫持和缓存投毒攻击
尤其在公共 Wi-Fi 网络上，未加密的 DNS 请求面临更高的被中间人（MITM）攻击截获和篡改的风险。攻击者伪造 DNS 响应将用户重定向到钓鱼网站，至今仍是一种普遍的威胁。
如何检测 DNS 泄漏
IP 确认酱提供 DNS 泄漏测试。测试的工作原理如下：
- 向一个唯一的测试子域名发出 DNS 请求
- 记录处理该请求的 DNS 解析器的 IP 地址
- 分析解析器的位置和 ISP 信息
- 检查结果中是否有来自 VPN 提供商 DNS 以外服务器的响应
如果在使用 VPN 时检测到 ISP 的 DNS 服务器或位于意外地区的服务器，则说明正在发生 DNS 泄漏。
逐步验证方法
- 连接 VPN 后访问 IP 确认酱，确认显示的 IP 地址属于你的 VPN 服务器
- 运行 DNS 泄漏测试，检查检测到的 DNS 服务器的 ISP 名称和位置
- 如果检测到的服务器属于你的 VPN 提供商，则是安全的。如果出现了你自己的 ISP 名称，则说明存在 DNS 泄漏
- 多次运行测试以确认结果一致（特别注意网络切换后的情况）
如何防止 DNS 泄漏
启用 VPN 的 DNS 泄漏保护
许多 VPN 服务内置了 DNS 泄漏保护功能。检查你的 VPN 客户端设置，确保该功能已启用。同时建议启用终止开关（VPN 断开时自动阻止所有流量的功能）。
手动配置 DNS 服务器
将 ISP 的 DNS 服务器替换为注重隐私的替代方案也是一种有效措施。Cloudflare 的 1.1.1.1 和 Google Public DNS（8.8.8.8）是常见选择。但请注意，使用这些公共 DNS 服务器并不会加密 DNS 请求本身。
禁用 IPv6
如果你的 VPN 不支持 IPv6，在操作系统网络设置中禁用 IPv6 可以防止通过 IPv6 的 DNS 泄漏。
控制 WebRTC
可以通过浏览器设置或 WebRTC Leak Prevent 等扩展来阻止 WebRTC 导致的信息泄漏。
采用 DNS over HTTPS (DoH) / DNS over TLS (DoT)
DoH 通过 HTTPS 发送 DNS 请求来加密，而 DoT 通过 TLS 加密。截至 2024 年，所有主流浏览器，Firefox、Chrome、Edge 和 Safari，都支持 DoH。如需全面了解这些协议，DNS 安全协议相关书籍是很有价值的参考资源。
DoH 和 DoT 各有利弊。DoH 使用 443 端口，与普通 HTTPS 流量无法区分，网络管理员难以阻止。DoT 使用 853 端口，网络管理员可以更容易地识别和控制 DNS 流量。企业网络倾向于使用 DoT，而 DoH 更适合个人使用。
截至 2025 年，Apple 的 iCloud Private Relay 和 Google 的 Encrypted Client Hello (ECH) 等技术正在进一步推动 DNS 加密。DNS 隐私保护是一个快速发展的领域。
DNS 安全协议比较
有多种技术可以增强 DNS 安全性，每种技术保护的范围和用途各不相同。在考虑 DNS 泄漏对策时，了解每种协议的特点非常重要。
DNSSEC（DNS 安全扩展）
DNSSEC 为 DNS 响应添加数字签名，能够检测响应是否被篡改。虽然对 DNS 缓存投毒有效，但它不会加密 DNS 请求的内容。这意味着即使部署了 DNSSEC，ISP 和网络管理员仍然可以看到你查询了哪些域名。DNSSEC 保证的是"响应的真实性"，与提供"通信机密性"的 DoH 和 DoT 互为补充。
DoH 与 DoT 的选择
DoH（DNS over HTTPS）和 DoT（DNS over TLS）都能加密 DNS 请求，但在运维特性上有所不同。DoH 使用 443 端口，与普通网页流量无法区分，在绕过审查和过滤方面很有效。但当企业安全策略需要监控和控制 DNS 流量时，这可能会带来问题。DoT 使用 853 端口，网络管理员更容易识别 DNS 流量，因此更适合企业环境。
Oblivious DoH (ODoH) 和 DNS over QUIC (DoQ)
从 2024 年到 2025 年，下一代 DNS 隐私技术正在走向实际部署。ODoH 在 DNS 解析器和客户端之间放置代理，使解析器在不知道客户端 IP 地址的情况下完成域名解析。由 Cloudflare 和 Apple 联合推动，它是 iCloud Private Relay 的底层技术。DoQ 通过 QUIC 协议加密 DNS，比基于 TCP 的 DoT 连接建立更快。AdGuard DNS 等部分提供商已开始支持。
通过组合这些技术，可以在多个层面降低 DNS 泄漏的风险。想要深入了解的读者，网络安全基础书籍有助于理解这些分层防御。不过，无论采用哪种技术，正确的防火墙配置仍然必不可少，建议使用规则阻止 VPN 隧道外的 DNS 流量。
DNS 泄漏与其他隐私风险
DNS 泄漏并非孤立存在，它与其他隐私风险密切相关。即使使用 VPN，如果发生 DNS 泄漏，ISP 可以看到你访问了哪些网站，基于 GeoIP 的位置估算可能会暴露你的真实位置。由于 DNS 请求包含目标域名，ISP 和中间方可以构建你浏览模式的详细画像。
从 2024 年到 2025 年，围绕 DNS 隐私的格局正在快速变化。Encrypted Client Hello (ECH) 的标准化正在推进，TLS 握手期间的服务器名称 (SNI) 正越来越多地被加密。将 DNS over HTTPS 与 ECH 结合使用，ISP 和网络管理员将更难确定你访问了哪些网站。另一方面，一些国家正在推动对这些加密技术的监管，隐私与监管之间的平衡正在被积极讨论。
你现在就能采取的行动
DNS 泄漏是一种常被忽视的隐私风险，即使在使用 VPN 时也可能发生。按照以下步骤立即验证你的网络环境：
- 在连接 VPN 的状态下访问 IP 确认酱首页，检查你的 IP 地址和 DNS 服务器信息
- 运行 DNS 泄漏测试，确认检测到的 DNS 服务器属于你的 VPN 提供商
- 如果出现了你自己的 ISP 名称，请在 VPN 客户端中启用 DNS 泄漏保护功能
- 在浏览器设置中启用 DoH（DNS over HTTPS），验证 DNS 请求是否已加密
- 在 Wi-Fi 和移动数据之间切换后立即运行测试，检查是否存在临时泄漏
- 定期重复测试，验证在 VPN 设置更改或操作系统更新后不会发生 DNS 泄漏