DoH

DoH（DNS over HTTPS，RFC 8484）把 DNS wire-format 查询与响应映射为 HTTPS 交换；它保护客户端到 DoH Resolver 的传输，但 Resolver 本身仍可见查询，也不等于 VPN 或 DNSSEC。

#concept #growing #network #dns

[!info] related notes

所属 MOC: DNS 知识地图

关系对比: DoH vs DoT

低延迟加密 DNS: DoQ

浏览器行为: 浏览器安全 DNS

隐私增强: ODoH

引导问题: DNS Bootstrap 鸡蛋问题

DoH

一句话定义

DoH（DNS over HTTPS） 是 RFC 8484 定义的 DNS 加密传输方式：客户端把标准 DNS wire-format 查询通过 HTTPS 发送给 DoH Resolver，再通过 HTTPS 收回 DNS 响应。

它改变的主要是：

客户端 ↔ 递归解析器这一段 DNS 报文如何传输。

DNS 的名称、记录类型、递归解析、缓存等基本语义并没有因为 DoH 而消失。

为什么需要它

经典 DNS 常直接通过 UDP/TCP 53 传输。若这一段没有额外保护，链路上的网络设备可能直接观察 DNS 查询内容，也更容易对报文实施篡改或重定向。

DoH 把这一段放进 HTTPS：

传统路径
Client ── DNS message ──> Recursive Resolver

DoH 路径
Client ── HTTPS{DNS message} ──> DoH Resolver

因此普通链路旁观者不能再像观察明文 DNS 那样直接读取每个查询中的域名。

核心心智模型

应用 / DoH Client
      │
      │ 生成普通 DNS Query
      ▼
DNS wire-format message
      │
      │ 映射为 HTTP GET 或 POST
      ▼
HTTPS / TLS
      │
      ▼
DoH Resolver
      │
      │ 取出 DNS Query
      ▼
缓存 / 正常递归 DNS
      │
      ▼
DNS Response
      │
      └── 通过 HTTPS 返回客户端

可以把它理解为：

DNS 语义
  ↓
HTTP 请求/响应
  ↓
TLS 保护
  ↓
网络传输

关键不是“DNS 变成了网页”，而是 DNS message 使用 HTTPS 作为承载。

一次标准 DoH 请求如何发生

RFC 8484 定义了两种标准请求方式。

GET

DNS wire-format 查询先做 base64url 编码，再放入 dns query parameter：

GET /dns-query?dns=<base64url-encoded-DNS-message>
Accept: application/dns-message

POST

DNS wire-format 查询直接作为 HTTP body：

POST /dns-query
Content-Type: application/dns-message
Accept: application/dns-message

<binary DNS wire-format message>

标准 wire-format media type 是：

application/dns-message

[!important] 一些服务商另外提供 JSON DNS API，但 JSON 不是 RFC 8484 所定义的标准 DNS wire-format 表示。因此不能把“GET/POST + JSON 或二进制”当成 DoH 标准模型。

DoH 真正保护了什么

DoH 主要保护：

DoH Client
    │
    │ 加密、完整性保护
    ▼
DoH Resolver

它降低了这一段被普通链路参与者直接读取或任意修改 DNS 查询内容的风险。

但加密终点就是 Resolver，因此：

DoH Resolver 通常仍然能够看到客户端向它提交的 DNS 查询。

如果目标是让单个解析参与者不能同时知道“客户端身份 + 查询内容”，需要看 ODoH 等不同隐私模型。

最小场景：浏览器 Secure DNS

浏览器可以直接实现 DoH：

Browser
   │
   ├── HTTPS 页面请求 ─────────> Website
   │
   └── DoH DNS 请求 ───────────> DoH Resolver

这意味着浏览器的 DNS 路径可能与操作系统其他程序不同。

例如：

Browser     → Public DoH Resolver
PowerShell  → System DNS
Other App   → VPN / Router DNS

因此“系统 DNS 已经改了”并不能证明浏览器一定走这条路径。完整机制见浏览器安全 DNS。

为什么常见于 443，但不要把 443 当成定义

DoH 使用 HTTPS URI，所以在没有指定其他端口时通常使用 HTTPS 的常见端口 443。

但协议本质是：

DNS over HTTPS

而不是：

“端口 443 上的 DNS”。

这也是为什么仅凭端口通常无法把 DoH 与普通 HTTPS 流量简单区分。

DoH 与专用 TCP 853 的 DoT 在这一点上的完整比较见 DoH vs DoT。

它不解决什么

不是 VPN

DoH 只处理 DNS 解析路径中的传输保护，不会自动把网页、SSH、游戏等所有网络流量装进统一加密隧道。

不会让 Resolver 看不到查询

Resolver 是 HTTPS 的终点，需要取得 DNS message 才能处理查询。

不等于 DNSSEC

DoH 保护的是客户端到 Resolver 的传输；DNSSEC 解决的是 DNS 数据真实性和完整性验证问题，两者职责不同。

不保证整台机器都使用 DoH

浏览器、操作系统、代理客户端和其他应用可以各自选择不同解析路径。

不隐藏所有网络元数据

后续访问目标服务时仍然需要建立真实网络连接。DoH 本身不提供完整的匿名化或流量隐藏。

仍可能存在 Bootstrap

如果 DoH endpoint 本身使用域名，客户端首先要知道如何连接这个 endpoint。这里会出现 DNS Bootstrap 鸡蛋问题。

如何观察和验证

理解 DoH 时优先观察“解析决策发生在哪里”，而不是只看一个 DNS 设置项：

当前应用是否自行启用了 Secure DNS / DoH？
DoH endpoint 是谁？
同机其他程序是否使用同一条解析路径？
抓包时是否还能直接看到对应的明文 DNS Query？
改变系统 DNS 后，当前应用的结果是否随之变化？

涉及实际故障时进入系统化 DNS 诊断流程，不要把完整排障流程继续塞进本概念笔记。

学习检查

先合上笔记再回答：

DoH 改变的是 DNS 的哪一部分：DNS 数据模型、递归算法，还是客户端到 Resolver 的传输方式？
画出一次 DoH 查询从 Client 到 Resolver 再返回的最小路径。
RFC 8484 的标准 DNS media type 是什么？GET 与 POST 分别如何携带 DNS message？
为什么 DoH Resolver 本身通常仍能看到查询内容？
为什么“浏览器开启 DoH”不能推出“整台电脑都在使用 DoH”？
DoH 为什么既不是 VPN，也不能替代 DNSSEC？
如果系统 DNS 修改后 Chrome 的解析结果完全不变，你下一步会检查什么？

掌握验收

能闭卷解释 DoH 的一句话定义和存在理由；
能画出 Client → HTTPS → DoH Resolver → DNS 的工作模型；
能说清 DoH 保护的信任边界以及 Resolver 仍能看到什么；
能解释 RFC 8484 的 GET / POST 与 application/dns-message；
能区分“浏览器使用 DoH”和“系统所有 DNS 都走 DoH”；
能通过 DoH vs DoT 处理一个新的加密 DNS 场景；
隔一段时间后仍能完成以上任务，再根据学习中的掌握调整 mastery。

规范与进一步阅读

RFC 8484 — DNS Queries over HTTPS (DoH): https://www.rfc-editor.org/rfc/rfc8484
DoH vs DoT
DoQ
ODoH
浏览器安全 DNS