9. Operational Considerations

Cette section conserve le texte RFC relatif à DNS over CoAP, y compris CoAP FETCH exchanges, application/dns-message Content-Format 553, SVCB docpath discovery, OSCORE and (D)TLS protection, CoAP caching, IANA registrations et operational/security considerations.

Texte RFC original

9.  Operational Considerations

9.1.  Coexistence of Different DNS and CoAP Transports

   Many DNS transports may coexist on the DoC server, such as DNS over
   UDP [STD13], DNS over (D)TLS [RFC7858] [RFC8094], DNS over HTTPS
   [RFC8484], or DNS over QUIC [RFC9250].  In principle, transports
   employing channel or object security should be preferred.  In
   constrained scenarios, DNS over CoAP is preferable to DNS over DTLS.
   The final decision regarding the preference, however, heavily depends
   on the use case and is therefore left to the implementers or users
   and is not defined in this document.

   CoAP supports Confirmable and Non-Confirmable messages [RFC7252] to
   deploy different levels of reliability.  However, this document does
   not enforce any of these message types, as the decision on which one
   is appropriate depends on the characteristics of the network where
   DoC is deployed.

9.2.  Redirects

   Application-layer redirects (e.g., HTTP) redirect a client to a new
   server.  In the case of DoC, this leads to a new DNS server.  This
   new DNS server may provide different answers to the same DNS query
   than the previous DNS server.  At the time of writing, CoAP does not
   support redirection.  Future specifications of CoAP redirect may need
   to consider the impact of different results between previous and new
   DNS servers.

9.3.  Proxy Hop Limit

   Mistakes might lead to CoAP proxies forming infinite loops.  Using
   the CoAP Hop-Limit option [RFC8768] mitigates such loops.

9.4.  Error Handling

   Section 4.3.1 specifies that DNS operational errors should be
   reported back to a DoC client using the appropriate DNS RCODE.  If a
   DoC client did not receive any successful DNS messages from a DoC
   server for a while, it might indicate that the DoC server lost
   connectivity to the upstream DNS infrastructure.  The DoC client
   should handle this error case like a recursive resolver that lost
   connectivity to the upstream DNS infrastructure.  In case of CoAP
   errors, the usual mechanisms for CoAP response codes apply.

9.5.  DNS Extensions

   DNS extensions that are specific to the choice of transport, such as
   described in [RFC7828], are not applicable to DoC.