Zum Hauptinhalt springen

Appendix B. Previous Work on DNS over HTTP or in Other Formats (先前关于DNS over HTTP或其他格式的工作)

在DoH标准化之前,已经有多个关于通过HTTP传输DNS或使用替代DNS格式的提案和实现。本附录总结了一些这些先前的工作。

Google DNS over HTTPS:

在DoH标准化之前,Google已经提供了一个JSON API用于DNS查询。这个API使用HTTP GET请求,并返回JSON格式的响应而不是DNS Wire Format。虽然这个API仍然可用,但它不符合本文档定义的DoH协议。

示例请求:

GET https://dns.google/resolve?name=example.com&type=A

响应是JSON格式的,包含查询结果的结构化表示。

Cloudflare DNS over HTTPS:

Cloudflare也提供了DNS over HTTPS服务,并且是DoH标准化工作的积极参与者。Cloudflare的服务支持本文档定义的DoH协议,使用"application/dns-message"媒体类型。

DNS Wire Format over HTTP:

一些早期的提案建议简单地将DNS Wire Format消息封装在HTTP中,而不使用专门的媒体类型或URI结构。这些提案影响了当前DoH协议的设计,但当前的协议更加结构化,更好地与HTTP的语义集成。

DNS-JSON:

一些提案建议使用JSON作为DNS数据的交换格式。JSON的优点包括人类可读性和与Web技术的良好集成。但是,JSON格式通常比DNS Wire Format更大,并且需要额外的解析和序列化逻辑。当前的DoH协议主要使用DNS Wire Format,但通过内容协商机制允许将来支持其他格式,包括JSON。

DNS over WebSockets:

一些实验性工作探索了使用WebSockets作为DNS传输。WebSockets提供了双向通信通道,可以支持服务器推送通知等功能。但是,WebSockets的复杂性和与现有HTTP基础设施的集成问题使得它们不太适合作为主要的DNS传输机制。

其他DNS传输协议:

除了DNS over HTTPS,还有其他几种提供安全DNS传输的协议:

  • DNS over TLS (DoT) [RFC7858]: 使用TLS直接保护DNS查询,使用专用端口853。DoT比DoH更简单,但不能利用HTTP的功能,并且可能更容易被识别和阻断。

  • DNS over QUIC (DoQ) [RFC9250]: 使用QUIC协议传输DNS查询。QUIC提供了低延迟和良好的移动性能,但是截至本文档编写时,QUIC的部署还不如HTTP/2广泛。

  • DNSCrypt: 一个较早的协议,用于加密DNS查询。DNSCrypt不是IETF标准,但有一些实现和部署。

教训和影响:

这些先前的工作为DoH的设计提供了宝贵的经验教训:

  1. 互操作性的重要性: 早期的专有实现显示了标准化协议的需求,以确保不同实现之间的互操作性。

  2. 性能考虑: DNS Wire Format的效率对于保持良好的性能很重要,特别是对于移动设备和低带宽连接。

  3. 隐私权衡: 不同的方法提供不同级别的隐私保护,并涉及不同的权衡。DoH旨在提供良好的隐私保护,同时保持与现有基础设施的兼容性。

  4. 与HTTP的集成: 充分利用HTTP的功能 (如缓存和内容协商) 可以提供显著的优势,但需要仔细设计以确保正确的语义。

  5. 部署实用性: 使用标准端口 (443) 和标准协议 (HTTPS) 使得DoH更容易部署,因为它可以利用现有的基础设施和防火墙规则。

当前的DoH协议代表了对这些先前工作的综合和改进,旨在提供一个标准化的、高效的、安全的DNS over HTTPS协议。

Letztes Update am