×
首页 » 教程 » DNS 是什么？为什么它是你上网隐私的最大盲区

DNS 是什么？为什么它是你上网隐私的最大盲区

📅 2026-02-23 👁️ 374 阅读

你每天都在用，却从未注意过的互联网基础设施

当你在浏览器里输入 ipinfo.im 并回车时，你的电脑并不知道这个域名对应的服务器 IP 是什么。它需要先问一个"翻译官"——DNS（Domain Name System，域名系统）。DNS 就像互联网的电话簿，把人类容易记忆的域名翻译成机器识别的 IP 地址（比如 104.21.35.12）。如果没有 DNS，整个互联网将无法运作，然而大多数用户从未配置过甚至思考过他们的 DNS 设置。

DNS 由 Paul Mockapetris 于 1983 年在 RFC 1035 中提出设计。当时的互联网是一个小型、可信的学术网络，安全并非设计重点。这一已有数十年历史的架构至今仍然是现代互联网的基础，这恰恰也是 DNS 成为普通用户最大隐私漏洞之一的根本原因。

DNS 查询的完整解析链路

DNS查询完整流程

一次典型的 DNS 查询会经历多个步骤，每一步都可能带来隐私暴露风险：

  1. 浏览器缓存：浏览器首先检查本地缓存中是否有该域名的历史解析记录。Chrome 等现代浏览器维护着独立于操作系统的 DNS 缓存。
  2. 操作系统缓存和 Hosts 文件：若浏览器缓存未命中，操作系统会查询自身的 DNS 缓存和本地 hosts 文件。Linux 和 macOS 的路径为 /etc/hosts，Windows 则位于 C:\Windows\System32\drivers\etc\hosts。
  3. 存根解析器到递归解析器：操作系统将查询发送至配置的 DNS 服务器，通常是你的 ISP 通过 DHCP 自动分配的递归解析服务器，由它完成后续的逐级查询工作。
  4. 根域名服务器：递归解析器向全球 13 组根服务器集群（编号 A 至 M）之一发起查询，以找到顶级域（如 .im）的权威服务器地址。
  5. 顶级域服务器：根服务器将解析器引导至 TLD 域名服务器，它知道哪台权威域名服务器负责处理 ipinfo.im 的记录。
  6. 权威域名服务器：权威服务器最终返回实际的 IP 地址记录（A 记录对应 IPv4，AAAA 记录对应 IPv6）。
  7. 响应与缓存：递归解析器根据记录的 TTL（生存时间）缓存结果，并将其返回给你的设备。浏览器随后才能与 Web 服务器建立 TCP/TLS 连接。

整个过程通常在 10~100 毫秒 内完成，用户几乎无感知。但这条链路上的每一个中间服务器都可能记录你的查询，形成一份详细的浏览历史记录。

隐私隐患：你的 DNS 查询完全暴露

传统 DNS 查询使用 UDP 53 端口，全程明文传输。这个源自 1983 年的架构决策在现代互联网中产生了巨大的隐私影响：

  • 运营商监控：你的 ISP 能看到你访问的每一个域名，构建完整的浏览画像。在很多国家，法律要求运营商根据数据留存法规保留这些数据数月甚至数年。
  • 公共 Wi-Fi 风险：在咖啡店或机场 Wi-Fi 环境下，攻击者使用 Wireshark 等工具即可轻松抓取所有 DNS 请求。一条简单的 UDP 53 端口抓包过滤规则就能实时揭示你正在访问的每一个网站。
  • DNS 劫持：中间人攻击者甚至你的 ISP 本身都可以伪造 DNS 响应，将你重定向到钓鱼网站、广告页面或监控端点。这无需复杂工具——只要能接入网络路径即可实施。
  • 政府审查：在很多国家，DNS 查询在国家层面被收集，用于内容审查和大规模监控项目。一些国家还部署了强制性的 DNS 拦截基础设施。

这就是为什么哪怕你使用了 HTTPS 加密网页内容，ISP 仍然知道你"去了哪些网站"——因为 DNS 查询发生在 HTTPS 连接建立之前，你要访问的域名在这一初始阶段以完全明文的方式传输。

DNS 劫持与投毒：真实世界的攻击场景

DNS 攻击并非纸上谈兵——它们在现实中频繁且大规模地发生：

  • DNS 缓存投毒：攻击者向递归解析器发送伪造的 DNS 响应，将恶意 IP 地址注入缓存。所有使用该解析器的用户都会被悄无声息地重定向到攻击者的服务器。2008 年的 Kaminsky 攻击证明了这种漏洞能够攻陷服务数百万用户的整个 ISP 级别解析器。
  • ISP 级别劫持：部分 ISP 会拦截不存在域名的查询（NXDOMAIN 响应），将用户重定向到广告页面而非显示标准错误。这种做法破坏了依赖准确 DNS 响应的应用程序，并违反了 DNS 协议规范。
  • BGP 劫持影响 DNS：2018 年 4 月，攻击者利用 BGP 路由劫持重定向了发往 Amazon Route 53 DNS 服务器的流量，从 MyEtherWallet 用户处窃取了约 15 万美元的加密货币。这次攻击证明 DNS 安全从根本上依赖于底层路由基础设施的完整性。
  • 国家级 DNS 操控：一些国家部署透明 DNS 代理，拦截所有 53 端口流量，无论用户手动配置了哪个 DNS 服务器。这使得传统的手动更换 DNS 服务器在没有加密的情况下毫无效果。

解决方案：加密你的 DNS

目前主流的两种 DNS 加密协议各有优劣，适用于不同的使用环境：

  1. DoH（DNS over HTTPS）：将 DNS 查询封装在标准 HTTPS 请求中，通过 443 端口传输。由于与普通网页流量使用相同端口，网络运营商几乎无法在不完全阻断所有 HTTPS 流量的情况下选择性封锁 DoH。Firefox、Chrome、Edge 和 Safari 在所有主要桌面和移动平台上均已原生支持。
  2. DoT（DNS over TLS）：在 853 端口上建立专用加密通道传输 DNS 查询。虽然加密强度与 DoH 相当，但专用端口使防火墙和网络管理员能够轻松检测和选择性封锁。Android 9 及更高版本原生支持（通过私密 DNS 功能），多数 Linux 发行版也通过 systemd-resolved 提供支持。

更新的协议 DNS over QUIC（DoQ） 也在逐步获得采用。它结合了加密隐私保护和更低延迟的优势，利用 QUIC 传输协议消除了 TCP 握手开销，并提供内置的连接迁移功能——这对于频繁在 Wi-Fi 和蜂窝网络之间切换的移动设备尤为实用。

各平台启用加密 DNS 的方法

Google Chrome

进入 设置 > 隐私和安全 > 安全 > 使用安全 DNS。选择 Cloudflare（1.1.1.1）或 Google（8.8.8.8）等提供商。当配置的服务器支持 DoH 时，Chrome 会自动使用加密 DNS，仅在 DoH 不可用时回退到传统 DNS。

Mozilla Firefox

前往 设置 > 隐私与安全 > DNS over HTTPS。Firefox 提供最大保护模式，当 DoH 服务器不可达时会拒绝回退到非加密 DNS，确保你的 DNS 查询即使在临时故障期间也不会被暴露。

Windows 11

打开 设置 > 网络和 Internet > Wi-Fi（或以太网）> DNS 服务器分配 > 编辑。输入支持 DoH 的服务器 IP 地址，在加密下拉菜单中选择仅加密（DNS over HTTPS）。此设置对所有应用程序全局生效。

macOS

从 macOS Ventura 开始，可以安装 DNS 配置描述文件来全局启用 DoH 或 DoT。从 DNS 提供商处下载签名描述文件（Cloudflare 和 NextDNS 均有提供），或使用开源的 dns-profile-creator 工具生成自定义描述文件。

Android

进入 设置 > 网络和互联网 > 私密 DNS，选择"私密 DNS 提供商主机名"。输入 DoT 主机名，如 one.one.one.one（Cloudflare）或 dns.google（Google）。这会使用 DNS over TLS 全局加密所有 DNS 流量。

推荐的公共加密 DNS 服务

服务商DoH 地址主 DNS隐私政策
Cloudflarehttps://cloudflare-dns.com/dns-query1.1.1.1日志 24 小时内清除
Googlehttps://dns.google/dns-query8.8.8.8临时日志，48 小时后匿名化
Quad9https://dns.quad9.net/dns-query9.9.9.9不记录个人数据，瑞士司法管辖
阿里 DNShttps://dns.alidns.com/dns-query223.5.5.5国内低延迟首选

DNSSEC：验证 DNS 响应的真实性

DoH 和 DoT 加密的是传输层，但它们并不验证 DNS 响应本身是否真实且未被修改。DNSSEC（DNS 安全扩展） 通过在权威服务器层面为 DNS 记录添加加密签名来解决这一互补性问题。

启用 DNSSEC 后，你的解析器可以通过加密方式验证 DNS 响应确实来自权威域名服务器，且在传输过程中未被篡改。这能防止缓存投毒和响应伪造攻击。但 DNSSEC 有重要局限性：它不加密查询内容（隐私并非其设计目标）、全球 DNS 基础设施的部署仍不完整，且配置错误的 DNSSEC 可能导致受影响域名完全无法解析。理想的安全态势是将 DNSSEC 验证与 DoH 或 DoT 加密结合使用，同时实现响应真实性和查询隐私保护。

DNS 泄漏测试：配置变更后的关键步骤

即使仔细配置了加密 DNS，由于系统错误配置、VPN 分流隧道策略、IPv6 回退行为或操作系统级别的 DNS 解析器回退机制，泄漏仍然可能发生。DNS 泄漏意味着你的查询被发送到了非预期的解析器——通常是你 ISP 的默认 DNS 服务器——尽管你已经进行了明确的隐私配置。

要测试 DNS 泄漏，请访问 ipinfo.im 并检查为你的连接显示的 ISP 字段。如果显示的 ISP 与你的本地宽带运营商一致，而非你的 VPN 或加密 DNS 提供商，说明你的 DNS 配置可能存在泄漏。你还应该验证 IP 地理位置是否与预期的 VPN 服务器位置一致，而非你的实际物理位置。每次网络配置变更、VPN 重新连接或操作系统更新后都进行此验证，是一项简单但至关重要的隐私卫生习惯，只需几秒钟即可完成。

命令行 DNS 验证方法

除了使用 ipinfo.im 进行快速可视化检查外，你还可以通过命令行验证当前活跃的 DNS 解析器，获得更技术化的确认。在 macOS 或 Linux 上，运行 dig +short whoami.cloudflare.com @1.1.1.1 TXT 来确认查询是否到达了 Cloudflare 的解析器。在 Windows 上，使用 nslookup ipinfo.im 并观察响应中的"服务器"字段——它显示的是实际应答你查询的 DNS 服务器。如果响应服务器的 IP 属于你的 ISP 而非配置的加密 DNS 提供商，说明你的 DNS 流量未被正确加密。定期的命令行验证有助于确保操作系统更新、网络变更或 VPN 断连没有悄然将你精心配置的 DNS 设置恢复为不安全的默认值。