基于HTTPS的DNS

基于HTTPS的DNS，简称DoH，是将一次DNS查询和对应回答映射为一次HTTPS交换的协议。保罗·霍夫曼与帕特里克·麦克马纳斯撰写的RFC 8484于2018年10月发布，RFC Editor将其列为建议标准。它主要讨论客户端与递归解析器之间的通信，不是重新定义整个域名系统。

客户端使用配置的HTTPS端点发出请求，并验证服务端身份。加密保护的是这段传输，不能据此断言递归解析器向其他DNS服务器发出的所有查询也采用相同方式。DoH仍要处理DNS记录、响应码和生存时间，只是将这些消息放入HTTP的请求与响应机制中。

参考：[1] [3]

RFC 8484要求服务器支持GET和POST。采用application/dns-message格式时，GET将DNS线格式消息作不带填充字符的base64url编码，放入名为dns的URI模板变量；POST则直接把二进制DNS消息置于请求正文，并用Content-Type说明格式。GET通常更适合既有HTTP缓存，POST不必把消息编码进地址。

例如，Google Public DNS将符合RFC 8484的dns-query端点与另一个只支持GET的JSON接口分开。因此，看到HTTPS上返回JSON的域名查询，不能直接认定其使用了规范的二进制消息格式。HTTP状态与DNS结果也不同：HTTP 200可携带表示域名不存在或解析失败的DNS回答，客户端还要检查内部响应码。

参考：[1] [2]

DoH同时面对HTTP缓存与DNS缓存。服务器应明确指定HTTP新鲜期；有回答记录时，该期限不得超过回答部分最小的TTL，以免HTTP层继续把已经过期的DNS数据当成新鲜内容。客户端还必须计入HTTP Age字段，不能每次从缓存读出消息就重新获得一整段TTL。

作为简化计算，某记录TTL为300秒，而HTTP响应已缓存80秒，则剩余寿命为220秒。POST响应在HTTP机制下并非绝对不能缓存，但RFC 8484指出所需支持不普遍，并不建议把它用于DoH的这种缓存安排。减少缓存有时有助于降低某些隐私风险，也可能增加解析延迟。

参考：[1] [2]

加密减少了路径上观察者直接读取DNS查询的机会，却不使解析器失去观察能力。解析器仍能接收查询，连接复用和部分HTTP头还可能帮助关联用户。流量大小、时间和其他可观察特征也留下分析空间；DoH没有把后续网站连接变成匿名通信，不能保证隐藏所有浏览目的地。

DNSSEC处理的是另一层问题：用数字签名及信任链验证DNS数据来源和完整性，本身不提供查询保密。HTTPS验证的是所连接的DoH服务器，并不自动证明它返回的权威数据真实。客户端可以自行验证DNSSEC，或明确依赖可信解析器的验证结果。DoH与DNSSEC可以并用，但任何一个都不能替代另一个的职责。

参考：[1] [3] [4]