加密 DNS 是什么
加密解析有两种主流形态：DNS over TLS 使用专门的 853 端口承载 TLS；DNS over HTTPS 把查询封装在 HTTPS 请求里走 443 端口。抓包里看不到明文的查询内容，只能从端口、连接形态与服务名一类线索去识别解析路径。这对排障影响很大：过去靠抓包验证域名级行为的方法在加密解析下失效，需要改用解析器侧日志或客户端指标。做内网排查时先确认终端到底走的是哪种解析方式，才能决定抓包点与后续手段。
基本信息
| 协议依据 | RFC 7858（DoT）、RFC 8484（DoH） |
|---|---|
| 端口特征 | DoT 使用 853，DoH 使用 443 |
| 抓包可见性 | 无明文查询内容，仅端口与连接形态可见 |
| 识别线索 | 853 上的持续 TLS 连接、TLS 握手里的服务名 |
| 替代手段 | 解析器日志、客户端指标与应用侧记录 |
典型使用场景
- 解析路径确认：判断终端使用的是明文解析还是加密解析
- 排障方案选择：加密解析场景改用日志与指标而不是抓包
- 策略验证：确认拦截加密解析后客户端是否回落到系统解析
- 流量区分：从端口与连接形态识别不同类型的解析流量
- 合规检查：确认内网是否允许绕过本地解析
识别线索
识别线索
tcp.port == 853 # DoT 连接
tls.handshake.extensions_server_name # 从服务名获取线索
# DoH 表现为 443 上的 HTTPS
# 不解密时与普通网页流量难以区分三种解析路径对比
| 形态 | 端口与承载 | 抓包可见性 |
|---|---|---|
| DoT | 853 上的持续 TLS 连接 | 无查询内容，可看端口与连接形态 |
| DoH | 443 上的 HTTPS 请求 | 需解密才可见，否则与网页流量难区分 |
| 明文解析 | 53 | 查询内容完全可见 |
加密解析场景下抓包无法验证域名级行为，必须换用解析器侧日志或客户端上报指标，否则排查会在错误的层面上打转。
策略拦截加密解析之后，浏览器可能静默回落到系统解析；观察时要分时段对比，否则会得出策略未生效的错误结论。