跳到主要内容

1. 简介

本文档定义 DNS over CoAP (DoC), 这是一种使用 OPCODE 0 (Query) 通过受限应用协议 (Constrained Application Protocol, CoAP) [RFC7252] 发送 DNS [STD13] 查询并获取 DNS 响应的协议. 每个 DNS 查询-响应对映射为一次 CoAP 消息交换. 每条 CoAP 消息都可以通过 DTLS 1.2 或更新版本 [RFC6347] [RFC9147], TLS 1.3 或更新版本 [RFC8323] [RFC8446], 或受限 RESTful 环境对象安全 (Object Security for Constrained RESTful Environments, OSCORE) [RFC8613] 的任意组合加以保护, 以确保消息完整性和机密性.

DoC 的应用用例受到 DNS over HTTPS (DoH) [RFC8484] 的启发. 然而, DoC 旨在部署于受限物联网 (Internet of Things, IoT), 这通常与 HTTPS 引入的要求相冲突. 受限 IoT 设备可能在内存, 功耗, 链路层帧大小, 吞吐量和延迟方面受到限制. 它们的 RAM 和 ROM 可能都只有几千字节. 它们可能长时间休眠, 之后需要刷新其已知的命名资源. 在这类场景中, 名称解析必须考虑仅有数百字节的链路层帧大小, 千比特每秒量级的比特率, 以及数秒级延迟 [RFC7228] [RFC7228bis].

为了不受 TCP 和 HTTPS 资源需求的负担, 受限 IoT 设备可以使用 DNS over DTLS [RFC8094]. 与 DNS over DTLS 相比, DoC 可以利用 CoAP 特性来缓解基于数据报通信的缺点. 这些特性包括: (1) 分块传输 (block-wise transfer) [RFC7959], 它解决了 DNS over DTLS 的路径 MTU 问题 (见 [RFC8094] 第 5 节); (2) CoAP 代理, 它们提供额外一级缓存; (3) 为应用流量和 DNS 信息复用数据结构, 从而节省受限设备上的内存.

为避免 UDP 之上的 DTLS 或 TLS 所需资源 (例如由 DNS over DTLS [RFC8094] 或 DNS over QUIC [RFC9250] 引入的资源需求), DoC 允许基于 OSCORE 的轻量级消息保护.

              . FETCH coaps://[2001:db8::1]/
             /
            /
          CoAP request
+------+  [DNS query]  +------+------+   DNS query     .--------------.
| DoC  |-------------->| DoC  | DNS  |--- --- --- --->|      DNS       |
|Client|<--------------|Server|Client|<--- --- --- ---| Infrastructure |
+------+ CoAP response +------+------+  DNS response   '--------------'
         [DNS response]
   \                         / \                                    /
    '-----DNS over CoAP-----'   '----DNS over UDP/HTTPS/QUIC/...---'

图 1: 基本 DoC 架构

DoC 最重要的组成部分可见于图 1: DoC 客户端通过向 DoC 服务器发送承载在 CoAP 请求中的 DNS 查询来尝试解析 DNS 信息. 该 DoC 服务器可以是所查询记录的权威名称服务器, 也可以是一个 DNS 客户端 (即存根解析器或递归解析器), 它在与上游 DNS 基础设施通信时, 使用 DNS over UDP [STD13], DNS over HTTPS [RFC8484] 或 DNS over QUIC [RFC9250] 等其他 DNS 传输来解析 DNS 信息. 随后, DoC 服务器使用这些信息, 以承载在 CoAP 响应中的 DNS 响应来答复 DoC 客户端的查询. DoC 服务器也可以作为 DNSSEC 验证器, 为资源受限程度更高的 DoC 客户端提供 DNSSEC 验证.

请注意, 本规范不同于 DoH, 因为它使用了 CoAP 专用的 FETCH 方法 [RFC8132]. 使用此方法的一个好处是, 像使用 POST 方法时那样将 DNS 查询放在 body 中, 同时又拥有使用 GET 方法的请求响应所具备的相同缓存优势. 将 DNS 查询放在 body 中意味着无需额外的 base64 编码, 这会降低代码复杂度并减小消息大小. 此外, 这也允许对查询进行分块传输 [RFC7959].

最后于 更新