[!info] related notes

• 所属 MOC: dns-moc
• 相关概念:
• 易混淆概念:
• 相关资源:

DoH vs DoT

范围

本文只比较：

• DoH（DNS over HTTPS，RFC 8484）
• DoT（DNS over TLS，RFC 7858）

两者都属于“客户端到递归 DNS Resolver”这一段的加密 DNS 传输方式。

共同点

两者首先解决的是同一类问题：

客户端
  │
  │ 传统 DNS 可能明文暴露查询
  ▼
递归解析器

使用 DoH 或 DoT 后，这一段建立加密传输，使链路上的普通旁观者不能像明文 DNS 那样直接读取和任意修改 DNS 报文。

但两者都不会让递归解析器本身看不到查询。如果关注“解析器同时知道客户端身份和查询内容”的问题，应继续看 ODoH。

核心结构差异

DoH

DNS message
   ↓
HTTP
   ↓
TLS
   ↓
HTTPS transport

RFC 8484 定义 DNS 查询通过 HTTPS 的 GET 或 POST 传输，标准 DNS wire-format media type 为 application/dns-message。

DoT

DNS message
   ↓
TLS
   ↓
TCP
   ↓
853（默认）

RFC 7858 为 DNS over TLS 分配默认 TCP 853。

关键对比

维度	DoH	DoT
标准	RFC 8484	RFC 7858
上层承载	HTTPS / HTTP 语义	TLS 直接承载 DNS
常见默认端口	HTTPS 常见 443	TCP 853
网络中是否容易按端口识别	与普通 HTTPS 共用 443，单靠端口难区分	853 明确表达 DoT
HTTP 能力	可使用 HTTP 请求、缓存、代理等语义	不经过 HTTP
常见部署形态	浏览器、应用、OS、代理均可实现	OS、路由器、stub/resolver 常见
对 Resolver 的信任	Resolver 仍可见查询	Resolver 仍可见查询

[!important] “DoH = 应用级、DoT = 系统级”只是常见部署倾向，不是协议强制属性。操作系统同样可以实现 DoH，应用也可以实现 DoT。

为什么 DoH 更难只靠端口区分

DoT 默认使用 853，因此网络设备可以基于端口直接知道：

这条连接很可能是 DNS over TLS。

DoH 使用 HTTPS URI，常见于 443，与大量普通 Web HTTPS 共用承载。

因此：

DoH 的流量分类不能只依赖“是不是 443”。

这也是企业网络、家长控制、VPN DNS 和浏览器 Secure DNS 之间容易出现控制权冲突的原因之一。

参见 浏览器安全 DNS。

为什么 DoT 的协议边界更明确

DoT 不把 DNS 映射成 HTTP 请求，而是为 DNS 建立 TLS 通道。

因此从协议职责看，它更直接：

DNS ↔ TLS ↔ TCP

网络设备也更容易识别并制定明确策略。

这种“容易识别”既可以用于管理，也意味着更容易被基于端口阻断；这里是协议属性带来的取舍，不是绝对优劣。

一个具体场景

假设公司网络要求内部域名：

git.internal.example

必须交给企业 DNS。

情况 A：系统统一配置 DoT

如果应用遵循系统解析路径：

App → System Resolver → DoT → 企业 Resolver

企业 DNS 策略比较集中。

情况 B：浏览器自行启用公共 DoH

可能出现：

Browser → Public DoH Resolver
其他程序 → System Resolver → 企业 DNS

于是同一台机器不同程序可能得到不同结果。

真正问题不是“DoH 一定错误”，而是解析控制面发生了分叉。

两者都不解决什么

DoH 和 DoT 都不自动解决：

• Resolver 本身的日志与隐私政策；
• DNS 数据来源真实性问题——见 DNSSEC；
• 访问目标 IP 的可见性；
• 整个网络流量的匿名化；
• 所有应用是否统一使用同一个解析路径；
• DoH/DoT 端点域名的 DNS Bootstrap 问题。

判断一个现场到底是 DoH 还是 DoT

优先看实际解析路径，而不是只看“系统里填了哪个 DNS”。

可以问：

1. 是浏览器自己发起，还是系统 stub 发起？
2. 连接目标是什么 Resolver？
3. 使用 443 HTTPS URI，还是 TCP 853？
4. 是否存在 VPN / 代理 / Secure DNS 覆盖？
5. 同机其他程序是否得到相同解析结果？

更完整排障见 系统化 DNS 诊断流程。

学习检查

不看上文回答：

1. DoH 与 DoT 保护的共同网络边界是哪一段？
2. 为什么“DoH = 应用级、DoT = 系统级”不够严谨？
3. 为什么 DoH 不能只通过“端口 443”与普通 HTTPS 区分？
4. 一个浏览器使用公共 DoH、系统使用企业 DoT 时，可能发生什么？
5. DoH/DoT 为什么都不能替代 DNSSEC？

资料

• DoH：RFC 8484 — https://www.rfc-editor.org/rfc/rfc8484
• DoT：RFC 7858 — https://www.rfc-editor.org/rfc/rfc7858