摘要

  • 受保护的 DoC 上下文只能证明客户端与共享该上下文的服务器之间的消息交换，不能说明服务器之后的 DNS 路径。
  • 发现来源、上下文建立、响应、上游传输、DNSSEC 判断和应用采用必须分别留存。

RFC 9953 将 DNS 查询和回答映射到 CoAP 交换。DTLS、TLS 或 OSCORE 可以保护这一段；这并不小，因为受限设备正需要这种边界清楚的能力。但它的边界不能被抹去。

RFC 明确指出，DoC 服务器可能与上游 DNS 基础设施进行未受保护的通信，例如 DNS over UDP。它也可能使用另一个受保护上下文，不过在协议层面对 DoC 客户端不可见。因此，客户端看到的安全首跳不能证明递归器、缓存、权威服务器或上游连接的状态。

服务器发现同样不是授权收据。客户端必须知道服务器与资源；自动配置只能来自可信来源。这支持配置来源的判断，不支持“该服务器验证了这个答案的 DNSSEC”或“应用已经接受这个名称”的结论。RFC 9953 把此类信任如何表达留在范围之外。

可审计记录应连接发现来源、URI、上下文及其有效期、查询、回答、声称上游时的对应证据、验证状态和本地决定。Christian Amsüss 是集体标准的共同作者之一，不是任何实际解析服务的运营者。

来源