4. Basic Message Exchange

この節では DNS over CoAP の RFC テキストを保持し, CoAP FETCH exchanges, application/dns-message Content-Format 553, SVCB docpath discovery, OSCORE and (D)TLS protection, CoAP caching, IANA registrations, operational/security considerations を扱う.

RFC 原文

4.  Basic Message Exchange

4.1.  The "application/dns-message" Content-Format

   This document defines a CoAP Content-Format ID for the Internet media
   type "application/dns-message" to be the mnemonic 553, based on the
   port assignment of DNS.  This media type is defined as in Section 6
   of [RFC8484], i.e., a single DNS message encoded in the DNS on-the-
   wire format [STD13].  Both DoC client and DoC server MUST be able to
   parse contents in the "application/dns-message" Content-Format.  This
   document only specifies OPCODE 0 (Query) for DNS over CoAP messages.
   Future documents can provide considerations for additional OPCODEs or
   extend its specification (e.g., by describing whether other CoAP
   codes need to be used for which OPCODE).  Unless another error takes
   precedence, a DoC server uses RCODE = 4, NotImp [STD13], in its
   response to a query with an OPCODE that it does not implement (see
   also Section 4.3.3).

4.2.  DNS Queries in CoAP Requests

   A DoC client encodes a single DNS query in one or more CoAP request
   messages that use the CoAP FETCH [RFC8132] request method.  Requests
   SHOULD include an Accept option to indicate the type of content that
   can be parsed in the response.

   Since CoAP provides reliability at the message layer (e.g., through
   Confirmable messages), the retransmission mechanism of the DNS
   protocol as defined in [STD13] is not needed.

4.2.1.  Request Format

   When sending a CoAP request, a DoC client MUST include the DNS query
   in the body of the CoAP request.  As specified in Section 2.3.1 of
   [RFC8132], the type of content of the body MUST be indicated using
   the Content-Format option.  This document specifies the usage of
   Content-Format "application/dns-message" (for details, see
   Section 4.1).

4.2.2.  Support of CoAP Caching

   The DoC client SHOULD set the ID field of the DNS header to 0 to
   enable a CoAP cache (e.g., a CoAP proxy en route) to respond to the
   same DNS queries with a cache entry.  This ensures that the CoAP
   Cache-Key (see [RFC8132], Section 2) does not change when multiple
   DNS queries for the same DNS data, carried in CoAP requests, are
   issued.  Apart from losing these caching benefits, there is no harm
   in not setting it to 0, e.g., when the query was received from
   somewhere else.  In any instance, a DoC server MUST copy the ID from
   the query in its response to that query.

4.2.3.  Example

   The following example illustrates the usage of a CoAP message to
   resolve "example.org.  IN AAAA" based on the URI
   "coaps://[2001:db8::1]/".  The CoAP body is encoded in the
   "application/dns-message" Content-Format.

   FETCH coaps://[2001:db8::1]/
   Content-Format: 553 (application/dns-message)
   Accept: 553 (application/dns-message)
   Payload (binary):
    00 00 01 00 00 01 00 00 00 00 00 00 07 65 78 61
    6d 70 6c 65 03 6f 72 67 00 00 1c 00 01

   Payload (human-readable):
    ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
    ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;example.org.             IN      AAAA

4.3.  DNS Responses in CoAP Responses

   Each DNS query-response pair is mapped to a CoAP request-response
   operation.  DNS responses are provided in the body of the CoAP
   response, i.e., it is also possible to transfer them using block-wise
   transfer [RFC7959].  A DoC server MUST be able to produce responses
   in the "application/dns-message" Content-Format (for details, see
   Section 4.1) when requested.  The use of the Accept option in the
   request is OPTIONAL.  However, all DoC clients MUST be able to parse
   an "application/dns-message" response (see also Section 4.1).  Any
   response Content-Format other than "application/dns-message" MUST be
   indicated with the Content-Format option by the DoC server.

4.3.1.  Response Codes and Handling DNS and CoAP Errors

   A DNS response indicates either success or failure in the RCODE of
   the DNS header (see [STD13]).  It is RECOMMENDED that CoAP responses
   that carry a parsable DNS response use a 2.05 (Content) response
   code.

   CoAP responses using non-successful response codes MUST NOT contain a
   DNS response and MUST only be used for errors in the CoAP layer or
   when a request does not fulfill the requirements of the DoC protocol.

   Communication errors with an upstream DNS server (e.g., timeouts)
   MUST be indicated by including a DNS response with the appropriate
   RCODE in a successful CoAP response, i.e., using a 2.xx response
   code.  When an error occurs at the CoAP layer, e.g., if an unexpected
   request method or an unsupported Content-Format in the request are
   used, the DoC server SHOULD respond with an appropriate CoAP error.

   A DoC client might try to repeat a non-successful exchange unless
   otherwise prohibited.  The DoC client might also decide to repeat a
   non-successful exchange with a different URI, for instance, when the
   response indicates an unsupported Content-Format.

4.3.2.  Support of CoAP Caching

   For reliability and energy-saving measures, content decoupling (such
   as en-route caching on proxies) takes a far greater role than it does
   in HTTP.  Likewise, CoAP makes it possible to use cache validation to
   refresh stale cache entries to reduce the number of large response
   messages.  For cache validation, CoAP implementations regularly use
   hashing over the message content for ETag generation (see [RFC7252],
   Section 5.10.6).  As such, the approach to guarantee the same cache
   key for DNS responses as proposed in DoH ([RFC8484], Section 5.1) is
   not sufficient and needs to be updated so that the TTLs in the
   response are more often the same regardless of query time.

   The DoC server MUST ensure that the sum of the Max-Age value of a
   CoAP response and any TTL in the DNS response is less than or equal
   to the corresponding TTL received from an upstream DNS server.  This
   also includes the default Max-Age value of 60 seconds (see
   Section 5.10.5 of [RFC7252]) when no Max-Age option is provided.  The
   DoC client MUST then add the Max-Age value of the carrying CoAP
   response to all TTLs in a DNS response on reception and use these
   calculated TTLs for the associated records.

   To meet the requirement for DoC, the RECOMMENDED algorithm for a DoC
   server is as follows: Set the Max-Age option of a response to the
   minimum TTL of a DNS response and subtract this value from all TTLs
   of that DNS response.  This prevents expired records from
   unintentionally being served from an intermediate CoAP cache.
   Additionally, if the ETag for cache validation is based on the
   content of the response, it allows that ETag not to change.  This
   then remains the case even if the TTL values are updated by an
   upstream DNS cache.  If only one record set per DNS response is
   assumed, a simplification of this algorithm is to just set all TTLs
   in the response to 0 and set the TTLs at the DoC client to the value
   of the Max-Age option.

   If shorter caching periods are plausible, e.g., if the RCODE of the
   message indicates an error that should only be cached for a minimal
   duration, the value for the Max-Age option SHOULD be set accordingly.
   This value might be 0, but if the DoC server knows that the error
   will persist, greater values are also conceivable, depending on the
   projected duration of the error.  The same applies for DNS responses
   that, for any reason, do not carry any records with a TTL.

4.3.3.  Examples

   The following example illustrates the response to the query
   "example.org.  IN AAAA record", with recursion turned on.  Successful
   responses carry one answer record including the address
   2001:db8:1:0:1:2:3:4 and TTL 79689.

   A successful response:

   2.05 Content
   Content-Format: 553 (application/dns-message)
   Max-Age: 58719
   Payload (human-readable):
    ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
    ;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;example.org.                 IN      AAAA
    ;; ANSWER SECTION:
    ;example.org.         79689   IN      AAAA    2001:db8:1:0:1:2:3:4

   When a DNS error - NxDomain (RCODE = 3) for "does.not.exist" in this
   case - is noted in the DNS response, the CoAP response still
   indicates success.

   2.05 Content
   Content-Format: 553 (application/dns-message)
   Payload (human-readable):
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 0
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;does.not.exist.              IN      AAAA

   As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if
   it does not support an OPCODE - in this case, it errors on a DNS
   Update (OPCODE = 5) for "example.org".

   2.05 Content
   Content-Format: 553 (application/dns-message)
   Payload (human-readable):
    ;; ->>Header<<- opcode: UPDATE, status: NOTIMP, id: 0
    ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUERY SECTION:
    ;example.org.                 IN      AAAA

   When an error occurs at the CoAP layer, the DoC server responds with
   an appropriate CoAP error, for instance, 4.15 (Unsupported Content-
   Format) if the Content-Format option in the request was not set to
   "application/dns-message" and the Content-Format is not otherwise
   supported by the server.

   4.15 Unsupported Content-Format
   [no payload]