跳到主要内容

3. DoC 服务器的选择 (Selection of a DoC Server)

虽然未为 DoC 资源指定路径, 但推荐 (RECOMMENDED) 使用根路径 "/", 以保持 CoAP 请求较小.

DoC 客户端需要知道 DoC 服务器以及 DoC 服务器上的 DoC 资源. 可用于确保这一点的选项包括: (1) 手动配置统一资源标识符 (Uniform Resource Identifier, URI) [RFC3986] 或受限资源标识符 (Constrained Resource Identifier, CRI) [CRI], 或 (2) 自动配置, 例如使用 CoRE 资源目录 [RFC9176], DHCP 或 Router Advertisement 选项 [RFC9463], 或发现指定解析器 [RFC9462]. 自动配置必须只来自可信来源.

3.1. 按资源类型发现 (Discovery by Resource Type)​

对于通过允许描述资源类型的链路机制发现 DoC 资源的场景 (例如 [RFC6690] 中的 Resource Type 属性), 本文档引入资源类型 "core.dns". 它可用于标识客户端可用的通用 DNS 解析器.

3.2. 使用 SVCB 资源记录或 DNR 发现 (Discovery Using SVCB Resource Records or DNR)​

也可以使用 Service Binding (SVCB) 资源记录 (RR) [RFC9460] [RFC9461] 发现 DoC 服务器. 这些记录通过另一个 DNS 服务解析, 例如由未加密的本地解析器提供. 也可以通过 DHCP 或 Router Advertisements 使用 Discovery of Network-designated Resolvers (DNR) 服务参数 [RFC9463] 发现 DoC 服务器. [RFC8323] 定义了 CoAP over TLS 服务器的 Application-Layer Protocol Negotiation (ALPN) ID, [RFC9952] 定义了 CoAP over DTLS 服务器的 ALPN ID. 只使用 OSCORE [RFC8613] 和 Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] 支持安全性的 DoC 服务器无法通过这些 SVCB RR 或 DNR 机制发现. COSE 表示 "Concise Binary Object Notation (CBOR) Object Signing and Encryption" [RFC9052]. 指定替代发现机制不在本文档范围内.

本文档不是 [RFC9460] 第 2.4.3 节所定义 CoAP scheme 的 SVCB 映射文档. 完整的 SVCB 映射在 [TRANSPORT-IND] 中规定. 它概括了所有 CoAP 服务的机制. 本文档仅引入 DoC 服务的发现.

本文档将 "docpath" 指定为单值 Service Parameter Key (SvcParamKey), 它对于 DoC SVCB 记录是强制性的. 如果缺少 "docpath" SvcParamKey, 则不应将该服务视为有效的 DoC 服务.

docpath 被划分为指向 DoC 资源的绝对路径段 (docpath-segment), 每个路径段是 1-255 个八位字节的序列. 在 ABNF [RFC5234] 中:

docpath-segment = 1*255OCTET

注意, 这将每个 docpath-segment 的长度限制为最多 255 个八位字节. 具有更长路径段的路径无法通过 "docpath" SvcParam 通告, 因此不推荐 (NOT RECOMMENDED) 将其用作 DoC 资源路径.

"docpath" 的表示格式值应 (SHALL) 是由 0 个或更多 docpath-segment 组成的逗号分隔列表 ([RFC9460] 附录 A.1). 根路径 "/" 由 0 个 docpath-segment 表示, 即空列表. 对于 zone-file 实现中的 docpath-segment 内 "," 和 "" 字符, 适用与 "alpn" SvcParam 中 alpn-id 相同的考虑事项 ([RFC9460] 第 7.1.1 节).

"docpath" 的线上格式值由 0 个或更多八位字节序列组成, 每个序列前带有一个作为单个八位字节的相应长度. 我们将这个单个八位字节称为长度八位字节. 长度八位字节和对应序列形成一个 length-value 对. 这些 length-value 对串接形成 SvcParamValue. 这些对必须正好填满 SvcParamValue; 否则, SvcParamValue 格式错误. 每个这样的 length-value 对表示指向 DoC 资源的绝对路径的一个段. 根路径 "/" 由 0 个 length-value 对表示, 即 SvcParamValue 长度为 0.

注意, 该格式使用与 "alpn" SvcParam 相同的编码, 因此可复用该 SvcParam 的解码器和编码器, 只需适配允许长度为零. 只要每个 docpath-segment 的长度在 0 到 23 个八位字节之间 (含端点), 就可以通过将每个长度八位字节与 CBOR 文本字符串主类型 3 (作为八位字节的 0x60; 见 [RFC8949]) 进行掩码处理, 轻松转换为 CRI [CRI] 中的路径表示. 此外, 如果所有 docpath-segment 的长度都在 0 到 12 个八位字节之间, 则可以通过将每个长度八位字节映射到对应 CoAP Uri-Path 选项的 Option Delta 和 Option Length, 轻松转换为一系列 CoAP Uri-Path 选项 (见 [RFC7252] 第 3.1 节). 同样, 它可以通过将每个长度八位字节替换为 "/" 字符, 转换为 URI 的 path-abempty 形式. 上述内容都不阻止使用比所考虑范围更长的 docpath-segment; 它们只是让转换更困难, 因为更长的分隔符需要空间, 进而需要移动八位字节.

要使用来自 SVCB RR 或 DNR Encrypted DNS 选项的服务绑定, DoC 客户端必须发送一个根据包含 "docpath" 的 SvcParams 构造的 DoC 请求. DoC 请求的构造算法如下, 按所提供记录的优先级顺序处理. 就该算法而言, 假定 DoC 客户端是 SVCB-optional (见 [RFC9460] 第 3 节).

  • 如果服务的 "alpn" SvcParam 值为 "coap", 则必须构造用于 CoAP over TLS 的 CoAP 请求 [RFC8323]. 如果值为 "co", 则必须构造用于 CoAP over DTLS 的 CoAP 请求 [RFC9952]. 指定传输的任何其他 SvcParamKey 不在本文档范围内.

  • 请求的目标地址应当 (SHOULD) 取自有关目标的附加信息. 这可能包括: (1) 与目标名称关联且随 SVCB RR 一起交付的 A 或 AAAA RR (见 [RFC9462]), (2) SVCB RR 中的 "ipv4hint" 或 "ipv6hint" SvcParam (见 [RFC9461]), 或 (3) 使用 DNR [RFC9463] 时提供的 IPv4 或 IPv6 地址. 作为回退, 可以从另一个 DNS 服务查询 SVCB 记录目标名称的地址.

  • 请求的目标端口必须取自 "port" SvcParam 值 (如果存在). 否则, 使用 CoAP 传输的默认端口. 例如, 就本规范而言, "coap" 的默认值是 TCP 端口 5684, "co" 的默认值是 UDP 端口 5684. 本文档不对可使用的端口引入限制. 如果恶意 SVCB 记录允许其发起者影响消息负载, [RFC9460] 第 12 节建议在 SVCB 映射文档中施加此类限制. 本文档使用的记录只影响 Uri-Path 选项. 该选项只在加密 (D)TLS 通道的明文中发送, 因此不需要任何限制.

  • 请求 URI 的 hostname 组件在通过 DNR 获得时必须是 Authentication Domain Name (ADN), 在通过 _dns 查询获得时必须是 SVCB 记录的目标名称 (如果使用 AliasMode, 则为 AliasMode 记录的目标名称). 这可以通过在 TLS Server Name Indication (SNI) [RFC8446] 中设置该名称, 或在每个请求上设置 Uri-Host 选项来高效实现.

  • 对于 "docpath" SvcParam 值的 CBOR 序列中的每个元素, 必须向请求添加一个 Uri-Path 选项.

  • 如果以这种方式构造的请求收到响应, 则未来 DoC 查询的构造必须使用同一 SVCB 记录. 如果没有收到响应, 或端点变得不可达, 算法会使用具有下一个最高 Service Priority 的 SVCB RR 或 DNR Encrypted DNS 选项作为回退并重复执行 (见 [RFC9460] 第 2.4.1 节和第 3 节).

[TRANSPORT-IND] 中可以找到适用于任意 CoAP 请求的更通用构造算法.

3.2.1. 示例 (Examples)​

DoC 服务器在服务器根路径 "/" 上的典型 SVCB 资源记录响应如下 ("docpath" SvcParam 是二进制中的最后 4 bytes 00 0a 00 00):

Resource record (binary):
 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
 67 00 00 40 00 01 00 00 06 28 00 1e 00 01 03 64
 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
 01 00 03 02 63 6f 00 0a 00 00

Resource record (human-readable):
 _dns.example.org.  1576  IN SVCB 1 dns.example.org (
     alpn=co docpath )

根路径是推荐的 (RECOMMENDED), 但不是必需的. 以下两个示例中, "docpath" 表示不同深度的路径. 首先, 下例提供 "/dns" (最后 8 bytes 为 00 0a 00 04 03 64 6e 73):

Resource record (binary):
 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
 67 00 00 40 00 01 00 00 00 55 00 22 00 01 03 64
 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
 01 00 03 02 63 6f 00 0a 00 04 03 64 6e 73

Resource record (human-readable):
 _dns.example.org.    85  IN SVCB 1 dns.example.org (
     alpn=co docpath=dns )

其次, 下面是路径 "/n/s" 的示例 (最后 8 bytes 为 00 0a 00 04 01 6e 01 73):

Resource record (binary):
 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
 67 00 00 40 00 01 00 00 06 6b 00 22 00 01 03 64
 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
 01 00 03 02 63 6f 00 0a 00 04 01 6e 01 73

Resource record (human-readable):
 _dns.example.org.   1643  IN SVCB 1 dns.example.org (
     alpn=co docpath=n,s )

如果服务器还提供 DNS over HTTPS, "dohpath" 和 "docpath" 可以 (MAY) 共存:

Resource record (binary):
 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
 67 00 00 40 00 01 00 00 01 ad 00 2c 00 01 03 64
 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
 01 00 06 02 68 33 02 63 6f 00 07 00 07 2f 7b 3f
 64 6e 73 7d 00 0a 00 00

Resource record (human-readable):
 _dns.example.org.   429  IN SVCB 1 dns.example.org (
     alpn=h3,co dohpath=/{?dns} docpath )
最后于 更新