跳到主要内容

9. 运行考量

9.1. 不同 DNS 和 CoAP 传输方式的共存

DoC 服务器上可以共存多种 DNS 传输方式, 例如 DNS over UDP [STD13], DNS over (D)TLS [RFC7858] [RFC8094], DNS over HTTPS [RFC8484] 或 DNS over QUIC [RFC9250]. 原则上, 应当优先选择采用通道安全或对象安全的传输方式. 在受限场景中, DNS over CoAP 优于 DNS over DTLS. 不过, 关于优先级的最终决定很大程度上取决于用例, 因此留给实现者或用户决定, 本文档不作定义.

CoAP 支持 Confirmable 和 Non-Confirmable 消息 [RFC7252], 用于部署不同级别的可靠性. 但是, 本文档不强制使用这些消息类型中的任何一种, 因为选择哪一种合适取决于部署 DoC 的网络特性.

9.2. 重定向

应用层重定向 (例如 HTTP) 会将客户端重定向到新的服务器. 对于 DoC, 这会指向新的 DNS 服务器. 这个新的 DNS 服务器可能会对同一个 DNS 查询给出与前一个 DNS 服务器不同的答案. 在本文撰写时, CoAP 不支持重定向. 未来的 CoAP 重定向规范可能需要考虑前后两个 DNS 服务器之间结果不同所带来的影响.

9.3. 代理跳数限制

错误可能导致 CoAP 代理形成无限循环. 使用 CoAP Hop-Limit 选项 [RFC8768] 可以缓解此类循环.

9.4. 错误处理

第 4.3.1 节规定, DNS 运行错误应当使用适当的 DNS RCODE 返回给 DoC 客户端. 如果 DoC 客户端一段时间内没有从 DoC 服务器收到任何成功的 DNS 消息, 这可能表明 DoC 服务器已失去与上游 DNS 基础设施的连通性. DoC 客户端应当像处理递归解析器失去与上游 DNS 基础设施连通性一样处理这种错误情况. 对于 CoAP 错误, 适用 CoAP 响应码的常规机制.

9.5. DNS 扩展

特定于传输方式选择的 DNS 扩展 (例如 [RFC7828] 中描述的扩展) 不适用于 DoC.