5. 与其他 CoAP 和 CoRE 特性的交互

5.1. DNS Push Notifications 和 CoAP Observe

DNS Push Notifications [RFC8765] 提供了以异步方式通知客户端资源记录变更的能力. 然而, 它会带来额外开销, 这与受限资源相冲突. 因此, 在 DoC 域中, 推荐使用 CoAP Observe [RFC7641] 而不是 DNS Push. 如果短生命周期记录被频繁请求, 这一点尤其有用. DoC server 应当在其 DoC resource 上提供 Observe 能力, 并按如下方式操作.

如果 DoC client 希望观察某个资源记录, DoC server 可以响应一个 notification, 并按照 [RFC7641] 将该客户端加入该资源的 list of observers. DoC server 可以为该记录订阅 DNS Push Notifications. 这涉及发送 DNS Subscribe 消息 (见 [RFC8765] 第 6.2 节), 而不是发送传统 DNS 查询来代表 DoC client 获取信息.

当某个特定 DNS 查询的 list of observers 变为空 (根据 [RFC7641] 第 3.6 节显式或隐式取消观察), 且没有其他理由继续订阅该请求时, DoC server 应当取消相应订阅. 这可能涉及发送 DNS Unsubscribe 消息或关闭会话 (见 [RFC8765] 第 6.4 节). 从 DoC server 的角度看, 此时已不再有 CoAP observer, 因此取消订阅失败或关闭会话失败无法传达回任何 DoC observer. 因此, 错误处理 (如果有) 需要在 DoC server 和上游 DNS 基础设施之间解决.

每当 DoC server 从 DNS 基础设施收到针对被观察资源记录的 DNS Push 消息时, DoC server 都会向 DoC client 发送适当的 Observe notification 响应.

以 notification 进行响应的服务器 (即发送 Observe 选项的服务器) 需要具备获取当前资源记录的手段. 这可以通过 DNS Push 实现, 也可以通过上游轮询或隐式情形实现 (例如, DoC server 是该记录的权威名称服务器并希望通知变更).

5.2. OSCORE

推荐在 DoC client 和 DoC server 之间承载使用 OSCORE [RFC8613] 保护的 DNS 消息. OSCORE 安全上下文的建立和维护不在本文档范围内.

[CACHEABLE-OSCORE] 描述了一种允许对 OSCORE 响应进行缓存检索的方法, 并讨论了这对消息大小和安全属性产生的相应影响.

5.3. 将 DoC 映射到 DoH

本文档没有规定如何在 DoC 和 DoH 之间进行映射, 例如在 CoAP-to-HTTP 代理处进行映射. 不推荐这种直接映射: 按照本文档所规定的方式重写 FETCH 方法 (第 4.2 节) 和 TTL (第 4.3.2 节) 并非易事. 推荐使用 DNS 转发器在 DoC 和 DoH 之间进行映射, 这与在任意其他一对 DNS 传输之间进行映射的情况相同.