DNS-over-HTTPS (DoH)

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

Google 公共 DNS 在这两个端点上提供两种不同的 DoH API:

  • https://dns.google/dns-query - RFC 8484(GET 和 POST)
  • https://dns.google/Resolve?– JSON API (GET)

安全传输概览页面提供了有关同时使用这两个 API 的 curl 命令行示例,以及 TLS 和 DNS-TLS (DoT) 和 DoH 通用的其他功能的详细信息。

仅支持 IPv6 的 Google 公共 DNS64 服务也支持 DoH。

Google 公共 DNS 不支持不安全的 http: 网址进行 API 调用。

HTTP 方法

获取
使用 GET 方法可以缩短延迟时间,因为它可以更高效地缓存。 RFC 8484 GET 请求必须具有包含 Base64Url 编码的 DNS 消息的 ?dns= 查询参数。GET 方法是 JSON API 支持的唯一方法。
POST
POST 方法仅受 RFC 8484 API 支持,并且使用二进制 DNS 消息,并在请求正文和 DoH HTTP 响应中显示 Content-Type application/dns-message。
HEAD
HEAD 目前不受支持,并返回 400 Bad Request 错误

其他方法会返回 501 Not Implemented 错误。

HTTP 状态代码

Google 公共 DNS DoH 会返回以下 HTTP 状态代码:

成功

200 OK
HTTP 解析以及与 DNS 解析器的通信成功,响应正文内容是二进制或 JSON 编码的 DNS 响应,具体取决于查询端点、Accept 标头和 GET 参数。

重定向

301 已永久移动
客户端应通过 Location: 标头中提供的网址重试。如果原始查询是 POST 请求,则只有在新网址指定了 dns GET 参数时,客户端才应使用 GET 重试;否则客户端应通过 POST 重试。

将来可能会使用“已找到 302”、“307 临时重定向”或“308 永久重定向”等其他代码,并且 DoH 客户端应处理所有这 4 个代码。

包含永久 301 和 308 代码的响应应该无限期地缓存,并且在实际情况下,系统可能会提示用户使用新网址更新其原始配置。

应始终通过 POST 重试收到 307 或 308 响应的 POST 请求。

错误

错误响应将使用 HTML 或纯文本来说明正文中的 HTTP 状态。

400 请求错误
解析 GET 参数方面的问题或 DNS 请求消息无效。 对于错误的 GET 参数,HTTP 正文应说明错误。大多数无效的 DNS 消息都会收到一条带有 FORMERR 的 200 OK 消息;没有问号的问题区块消息、表示回复的二维码或包含二进制 DNS 解析错误的其他无意义标志组合都会返回 HTTP 错误。
413 载荷过大
RFC 8484 POST 请求正文超出了 512 字节的消息大小上限。
414 URI 过长
GET 查询标头过大,或 dns 参数的 Base64Url 编码的 DNS 消息超出了消息大小上限(512 字节)。
415 媒体类型不受支持
POST 正文没有 application/dns-message Content-Type 标头。
429 请求过多
客户在给定时间内发送的请求过多。客户端应停止发送请求,直到 Retry-After 标头中指定的时间(以秒为单位的相对时间)。
500 内部服务器错误
Google 公共 DNS 内部 DoH 错误。
501 未实施
仅实现了 GET 和 POST 方法,其他方法会遇到此错误。
502 Bad Gateway
DoH 服务无法连接到 Google 公共 DNS 解析器。

如果收到 502 响应,虽然使用备用 Google 公共 DNS 地址重试可能会有所帮助,但更有效的回退响应是尝试其他 DoH 服务,或改用 8.8.8.8 上的传统 UDP 或 TCP DNS。

DoH 的优势

HTTPS(而不仅仅是 TLS 加密)具有一些实际优势:

  • 全面支持和支持的 HTTPS API 简化了 Google 公共 DNS 本身和潜在客户的实现。
  • HTTPS 服务可为 Web 应用提供访问所有 DNS 记录类型的权限,从而避免对现有浏览器和操作系统 DNS API 施加限制,这些 API 通常仅支持主机到地址查找。
  • 实现基于 UDP 的 HTTPS 支持的客户端可以避免在使用 TCP 传输时可能出现的队头阻塞之类的问题。

卫生部的隐私权最佳做法

DoH 应用的开发者应考虑 RFC 8484 中概述的隐私权最佳做法(如下所述):

  • 限制 HTTP 标头的使用

    HTTP 标头会提供有关客户端的 DoH 实现的信息,并可用于对客户端进行去匿名化处理。Cookie、User-Agent 和 Accept-Language 等标头是最严重的违规内容,但即便是发送的标头集也可能会泄露。为了尽量降低这种风险,请仅发送 DoH 所需的 HTTP 标头:主机、内容类型(对于 POST),如有必要,请接受。任何开发或测试版本都应包含用户代理。

  • 使用 EDNS 填充选项

    按照 RFC 8467 中的指南,使用 EDNS 填充选项将 DoH 查询填充为几种常见的长度,以防止流量分析。还可以使用 HTTP/2 填充,但与 EDNS 填充不同,在来自 DoH 服务器的响应时不会引入填充。

  • RFC 8484 POST 方法仅适用于隐私敏感应用或浏览器模式

    对 DoH 查询使用 POST 会降低响应的可缓存性,并且可能增加 DNS 延迟时间,因此通常不建议这样做。但是,降低对隐私敏感应用的缓存可取的做法,或许可以防止 Web 应用尝试确定用户最近访问过哪些网域的时间计时攻击。

问题

如需报告 bug 或请求新功能,请打开 DoH 问题