5. Interaction with Other CoAP and CoRE Features

Dieser Abschnitt bewahrt den RFC-Text zu DNS over CoAP, einschliesslich CoAP FETCH exchanges, application/dns-message Content-Format 553, SVCB docpath discovery, OSCORE and (D)TLS protection, CoAP caching, IANA registrations und operational/security considerations.

Originaler RFC-Text

5.  Interaction with Other CoAP and CoRE Features

5.1.  DNS Push Notifications and CoAP Observe

   DNS Push Notifications [RFC8765] provide the capability to
   asynchronously notify clients about resource record changes.
   However, it results in additional overhead, which conflicts with
   constrained resources.  This is the reason why it is RECOMMENDED to
   use CoAP Observe [RFC7641] instead of DNS Push in the DoC domain.
   This is particularly useful if a short-lived record is requested
   frequently.  The DoC server SHOULD provide Observe capabilities on
   its DoC resource and do as follows.

   If a DoC client wants to observe a resource record, a DoC server can
   respond with a notification and add the client to its list of
   observers for that resource in accordance with [RFC7641].  The DoC
   server MAY subscribe to DNS Push Notifications for that record.  This
   involves sending a DNS Subscribe message (see Section 6.2 of
   [RFC8765]), instead of a classic DNS query to fetch the information
   on behalf of the DoC client.

   After the list of observers for a particular DNS query has become
   empty (by explicit or implicit cancellation of the observation as per
   Section 3.6 of [RFC7641]), and no other reason to subscribe to that
   request is present, the DoC server SHOULD cancel the corresponding
   subscription.  This can involve sending a DNS Unsubscribe message or
   closing the session (see Section 6.4 of [RFC8765]).  As there is no
   CoAP observer anymore from the perspective of the DoC server, a
   failure to unsubscribe or close the session cannot be communicated
   back to any DoC observer.  As such, error handling (if any) needs to
   be resolved between the DoC server and the upstream DNS
   infrastructure.

   Whenever the DoC server receives a DNS Push message from the DNS
   infrastructure for an observed resource record, the DoC server sends
   an appropriate Observe notification response to the DoC client.

   A server that responds with notifications (i.e., sends the Observe
   option) needs to have the means of obtaining current resource
   records.  This may happen through DNS Push or also by upstream
   polling or implicit circumstances (e.g., if the DoC server is the
   authoritative name server for the record and wants to notify about
   changes).

5.2.  OSCORE

   It is RECOMMENDED to carry DNS messages protected using OSCORE
   [RFC8613] between the DoC client and the DoC server.  The
   establishment and maintenance of the OSCORE security context is out
   of the scope of this document.

   [CACHEABLE-OSCORE] describes a method to allow cache retrieval of
   OSCORE responses and discusses the corresponding implications on
   message sizes and security properties.

5.3.  Mapping DoC to DoH

   This document provides no specification on how to map between DoC and
   DoH, e.g., at a CoAP-to-HTTP proxy.  Such a direct mapping is NOT
   RECOMMENDED: Rewriting the FETCH method (Section 4.2) and TTL
   (Section 4.3.2) as specified in this document would be non-trivial.
   It is RECOMMENDED to use a DNS forwarder to map between DoC and DoH,
   as would be the case for mapping between any other pair of DNS
   transports.