为什么 DNS 查询会暴露你访问的域名：从明文 DNS 到加密 DNS
访问一个网站时，我们通常只关注 HTTPS 是否安全，却很容易忽略另一个问题：
在建立 HTTPS 连接之前，DNS 查询本身可能还是明文的。
例如访问：
https://www.example.com浏览器首先需要知道 www.example.com 对应的 IP 地址，因此会发起 DNS 查询。
传统 DNS 通常使用 UDP 53 端口：
电脑
│
│ DNS Query
│ www.example.com
│ UDP/53
▼
DNS Server这个查询默认没有加密。
这意味着本地网络、路由器、运营商以及网络路径中的相关设备，都有机会直接看到：
www.example.com
github.com
google.com
api.example.com加密 DNS 的目的，就是解决这个问题。
1. DNS 是什么
DNS，全称：
Domain Name System主要负责将域名转换成 IP 地址。
例如：
www.example.com
│
▼
DNS 查询
│
▼
93.184.216.34浏览器拿到 IP 以后，才能继续建立 TCP、QUIC、TLS 等连接。
完整过程大致为：
输入网址
│
▼
DNS 查询域名
│
▼
获取服务器 IP
│
▼
建立 TCP / QUIC 连接
│
▼
TLS 握手
│
▼
HTTPS 请求
│
▼
服务器返回页面所以即使最终使用的是 HTTPS：
https://www.example.com在 HTTPS 连接建立之前，DNS 查询就已经发生了。
2. 为什么传统 DNS 会暴露域名
传统 DNS 一般使用：
UDP 53部分情况下也会使用：
TCP 53例如：
192.168.1.100
│
│ UDP 53
│ A www.example.com
▼
1.1.1.1问题在于：
传统 DNS 协议本身没有提供传输层加密。
因此抓取网络数据包，可以直接看到 DNS 请求内容。
例如 Wireshark 中可能看到：
Standard query A www.example.com甚至可以直接看到：
Domain Name System (query)
Queries
www.example.com
Type: A
Class: IN也就是说：
电脑
│
│ 明文 DNS
▼
路由器
│
▼
运营商
│
▼
网络中间设备
│
▼
DNS Server在这条路径上，有能力观察网络流量的设备都有可能知道：
你正在查询什么域名3. HTTPS 为什么不能保护 DNS
一个常见误区是：
网站已经使用 HTTPS，为什么 DNS 还是明文？
因为 DNS 通常发生在 HTTPS 之前。
例如：
① DNS 查询
www.example.com -> 93.184.216.34
② TCP / QUIC 建立连接
③ TLS 握手
④ HTTPS 请求
GET /HTTPS 加密的是：
HTTP 请求内容
Cookie
Header
POST 数据
网页内容但传统 DNS 查询：
www.example.com在 TLS 建立之前就已经发出。
因此：
HTTPS并不能自动保护传统 DNS。
4. 中间网络设备能够看到什么
假设使用传统 DNS：
客户端
│
│ UDP/53
│ www.example.com
▼
DNS Server网络中间设备可以直接读取：
查询域名：www.example.com
查询类型：A
DNS Server 地址
客户端 IP例如运营商侧观察到：
10:00:01 -> DNS 查询 github.com
10:00:10 -> DNS 查询 youtube.com
10:02:32 -> DNS 查询 example.com虽然这并不等同于看到了 HTTPS 中传输的具体内容，但域名本身已经能够暴露不少访问行为。
5. 如何验证 DNS 是不是明文的
可以直接使用 Wireshark 抓包。
选择网卡
选择当前真正联网的网卡，例如：
Wi-Fi
Ethernet
en0
en7macOS 可以执行：
route get default查看：
interface: en0Wireshark 过滤 DNS
使用：
dns或者：
udp.port == 53如果同时希望检查 TCP DNS：
udp.port == 53 || tcp.port == 53然后访问网站，例如：
https://www.wikipedia.org如果看到：
Standard query A www.wikipedia.org说明这个 DNS 查询是明文的。
6. 使用 dig 主动生成 DNS 请求
为了避免浏览器缓存、系统缓存等影响，可以直接使用 dig。
例如：
dig @1.1.1.1 www.example.com此时 Wireshark 可以看到：
你的电脑
│
│ UDP 53
▼
1.1.1.1对应请求：
Standard query A www.example.com响应：
Standard query response
A www.example.com
A 93.184.216.34这是一种非常直观的传统 DNS 明文测试方法。
7. 什么是加密 DNS
加密 DNS 的目标是：
对客户端到 DNS Server 之间的 DNS 查询进行加密。
目前比较常见的协议有：
| 协议 | 全称 | 常用端口 | 底层协议 |
|---|---|---|---|
| DNS | Domain Name System | 53 | UDP / TCP |
| DoT | DNS over TLS | 853 | TLS |
| DoH | DNS over HTTPS | 443 | HTTPS |
| DoQ | DNS over QUIC | 853 | QUIC |
传统 DNS：
客户端
│
│ UDP 53
│ www.example.com
▼
DNS Server加密 DNS：
客户端
│
│ TLS / HTTPS / QUIC
│ 加密数据
▼
DNS Server这样网络中间设备只能看到：
客户端正在连接某个 DNS Server无法直接读取其中的：
www.example.com8. DoH：DNS over HTTPS
DoH 是目前非常常见的加密 DNS 方案。
它将 DNS 查询放进 HTTPS 请求中：
DNS Query
│
▼
HTTPS
│
▼
TLS
│
▼
TCP 443网络结构：
客户端
│
│ HTTPS :443
▼
DoH Server例如常见 DoH 地址：
https://cloudflare-dns.com/dns-query
https://dns.google/dns-query
https://dns.alidns.com/dns-query在 Wireshark 中通常只能看到：
TLS Application Data无法直接看到：
www.example.com9. DoT：DNS over TLS
DoT 使用 TLS 加密 DNS：
DNS
│
▼
TLS
│
▼
TCP 853结构：
客户端
│
│ TCP 853
│ TLS
▼
DoT Server传统 DNS 和 DoT 很容易通过端口区分：
53 -> 传统 DNS
853 -> DoT10. DoQ：DNS over QUIC
DoQ 使用 QUIC 传输 DNS：
DNS
│
▼
QUIC
│
▼
UDP网络中通常表现为：
UDP 853
QUIC其中 DNS 内容同样经过加密。
11. DoH、DoT、DoQ 怎么选
日常网络环境可以简单这样选择：
| 协议 | 兼容性 | 特点 |
|---|---|---|
| DoH | 很高 | 使用 HTTPS 443，兼容性最好 |
| DoT | 高 | 独立 TCP 853，协议清晰 |
| DoQ | 较高 | 使用 QUIC |
| 普通 DNS | 极高 | 明文 |
一般情况下推荐：
DoH原因很简单：
HTTPS
TCP 443
网络兼容性好如果软件和网络环境支持，也可以考虑：
DoQ12. 如何配置加密 DNS
具体方式取决于操作系统和软件。
通常需要配置一个 DoH Server，例如：
https://dns.alidns.com/dns-query或者：
https://cloudflare-dns.com/dns-query核心结构应该变成：
应用
│
▼
系统 DNS Resolver
│
▼
DoH
│
│ HTTPS 443
▼
DNS Server而不是：
应用
│
▼
系统 Resolver
│
│ UDP 53
▼
DNS Server13. 如何验证加密 DNS 是否生效
配置完成以后，重新使用 Wireshark 抓包。
首先过滤传统 DNS：
udp.port == 53 || tcp.port == 53然后访问几个新的域名，例如：
www.wikipedia.org
www.cloudflare.com
github.com如果加密 DNS 工作正常，不应该在传统 DNS 包中看到这些域名。
例如不应该看到：
Standard query A github.com而应该看到类似：
客户端 -> DNS Server
TCP 443
TLS
Application Data如果使用 DoQ，则可能看到：
UDP 853
QUIC但无法直接读取：
github.com14. 如何验证得更准确
测试时建议避免 DNS 缓存影响。
可以选择之前没有访问过的域名，或者使用随机子域名，例如：
test-123456.example.com因为如果域名已经存在系统 DNS Cache：
应用
│
▼
系统缓存
│
▼
直接返回 IP此时根本不会产生 DNS 网络请求。
所以：
抓不到 DNS并不一定代表使用了加密 DNS，也可能只是：
DNS 缓存命中15. 加密 DNS 能保护什么
使用 DoH、DoT、DoQ 后，主要保护的是：
DNS Query
DNS Response例如：
www.example.com不会再以明文形式出现在：
客户端
↓
路由器
↓
运营商
↓
DNS Server这条路径中。
因此中间网络设备无法直接通过 DNS 数据包知道：
你正在解析哪个域名16. 加密 DNS 不能保护什么
需要特别注意：
加密 DNS 不等于匿名上网，也不等于隐藏所有访问行为。
即使 DNS 已经加密，中间网络设备仍然可以看到：
你的 IP 地址
目标服务器 IP
连接端口
数据包大小
连接时间
流量特征例如：
192.168.1.100
│
│ HTTPS
▼
142.x.x.x:443虽然无法通过 DNS 包直接看到：
www.example.com但目标服务器 IP 仍然是可见的。
17. TLS SNI 也可能暴露域名
DNS 加密之后，还有另外一个可能暴露域名的位置：
TLS SNI传统 TLS 握手中，客户端可能发送：
Server Name: www.example.com因此会出现：
DNS
│
│ DoH
│ 已加密
▼
TLS ClientHello
│
│ SNI: www.example.com
▼
服务器目前 TLS 中还有：
ECH
Encrypted Client Hello用于进一步保护这部分信息。
因此真正完整的访问隐私问题，需要分别考虑：
DNS
TLS SNI
目标 IP
流量特征加密 DNS 只解决其中：
DNS 查询隐私这一部分。
18. DNS Server 本身仍然能看到查询
使用 DoH：
客户端
│
│ 加密
▼
DNS Server加密发生在：
客户端 <-> DNS Server之间。
DNS Server 收到请求后仍然需要知道：
www.example.com才能完成解析。
因此：
局域网设备
路由器
运营商
中间网络设备通常无法直接读取 DNS 查询内容。
但：
DNS Server本身依然能够知道你查询了什么域名。
所以选择可信的 DNS 服务商仍然很重要。
19. 明文 DNS、加密 DNS 和匿名访问的区别
明文 DNS
客户端
│
│ www.example.com
▼
DNS Server中间设备可以读取域名。
加密 DNS
客户端
│
│ ************
▼
DNS Server中间设备无法直接读取 DNS 内容。
DNS Server 能看到查询内容。
VPN / 代理
如果目标是隐藏更多网络路径信息，则需要考虑：
VPN
Proxy
Encrypted Tunnel例如：
客户端
│
│ 加密隧道
▼
VPN Server
│
▼
互联网此时本地 ISP 看到的主要是：
客户端 <-> VPN Server而不是所有最终目标服务器连接。
因此：
加密 DNS ≠ VPN它们解决的是不同问题。
20. 最终网络结构对比
普通 DNS
可以读取 DNS
↓
客户端 ─── 路由器 ─── ISP ─── 网络 ─── DNS Server
│
└── UDP 53
www.example.com加密 DNS
客户端 ─── 路由器 ─── ISP ─── 网络 ─── DNS Server
│ │
│ TLS / HTTPS / QUIC │
└──────── 加密 DNS ────────────────────┘
中间设备：
只能看到加密连接
DNS Server：
可以看到 www.example.com21. 推荐的验证流程
第一步：抓传统 DNS
Wireshark：
udp.port == 53 || tcp.port == 53访问几个新的域名。
如果能看到：
Standard query A www.example.com说明存在明文 DNS。
第二步：开启 DoH / DoT / DoQ
配置加密 DNS。
例如：
DoH
https://dns.alidns.com/dns-query第三步：重新抓包
再次访问新的域名。
如果传统 DNS 包中不再出现：
www.example.com而只看到：
TLS
HTTPS
QUIC说明 DNS 查询已经被加密。
第四步：检查目标 DNS Server
还需要确认：
这些加密 DNS 请求最终连接的是不是自己配置的 DNS Server避免虽然使用了加密 DNS，但实际连接的 DNS 服务商与预期不一致。
总结
传统 DNS 最大的问题是：
DNS 查询默认可以明文传输例如：
www.example.com可能直接出现在 UDP 53 数据包中。
因此：
局域网
路由器
运营商
其他网络中间设备都有可能看到这些域名查询。
使用：
DoH
DoT
DoQ以后，可以将：
客户端 <-> DNS Server之间的 DNS 查询进行加密。
网络模型由：
客户端
│
│ UDP 53
│ www.example.com
▼
DNS Server变成：
客户端
│
│ TLS / HTTPS / QUIC
│ ***************
▼
DNS Server此时中间网络设备无法直接读取 DNS 查询内容。
但需要明确：
加密 DNS 保护的是 DNS 查询本身的隐私，并不能隐藏完整的网络访问行为。
即使开启了加密 DNS：
目标 IP
连接时间
流量大小
部分 TLS 元数据仍然可能暴露。
因此从网络隐私角度，可以把几个问题分开理解：
DNS 查询隐私
↓
DoH / DoT / DoQ
TLS 域名隐私
↓
ECH
网络路径隐私
↓
VPN / Proxy / Tunnel而加密 DNS 解决的，就是其中最基础的一环：
防止 DNS 查询域名以明文形式暴露在网络传输路径中。