Summary

  • RFC 9953 can protect a DNS message between a DoC client and the DoC server that shares its security context; it does not expose or certify the server's upstream DNS hop.
  • Trusted discovery, context establishment, response handling, upstream transport, DNSSEC validation and application acceptance are separate, time-bound records.

A constrained device may send its DNS question in a CoAP FETCH request and receive the DNS reply in a CoAP response. DTLS, TLS or OSCORE can protect that exchange. This is useful precisely because the claim is narrow: the message was protected between the endpoints of the relevant context.

The next hop belongs to another ledger. RFC 9953 says a DoC server may communicate with upstream DNS infrastructure without protection, for example through DNS over UDP. It may instead use a separate protected context, but that fact is opaque to the DoC client at protocol level. A green client-to-server security indication therefore cannot prove how the server reached an authority, cache, recursive resolver or forwarder.

Server selection deserves the same restraint. A client must know the server and resource; automatic configuration must come from a trusted source. That supports a configuration provenance claim, not an assertion that the server is the correct recursive operator, validates DNSSEC for this answer, or is authorized by every application that uses the name. RFC 9953 says how trust in server-side DNSSEC validation is expressed is outside its scope.

The practical record has joins: discovery source and time; selected URI; negotiated or established security context; query and response identifiers; server response; upstream evidence where claimed; validation status; and the client or application decision. Dropping those joins replaces running evidence with a friendly label. Amsüss is one collective author of the standard, not an operator of any named resolver or deployment.

Sources