1. Introduction

この節では 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 原文

1.  Introduction

   This document defines DNS over CoAP (DoC), a protocol to send DNS
   [STD13] queries and get DNS responses over the Constrained
   Application Protocol (CoAP) [RFC7252] using OPCODE 0 (Query).  Each
   DNS query-response pair is mapped into a CoAP message exchange.  Each
   CoAP message can be secured by any combination of DTLS 1.2 or newer
   [RFC6347] [RFC9147], TLS 1.3 or newer [RFC8323] [RFC8446], or Object
   Security for Constrained RESTful Environments (OSCORE) [RFC8613] to
   ensure message integrity and confidentiality.

   The application use case of DoC is inspired by DNS over HTTPS (DoH)
   [RFC8484].  However, DoC aims for deployment in the constrained
   Internet of Things (IoT), which usually conflicts with the
   requirements introduced by HTTPS.  Constrained IoT devices may be
   restricted in memory, power consumption, link-layer frame sizes,
   throughput, and latency.  They may only have a handful kilobytes of
   both RAM and ROM.  They may sleep for long durations of time, after
   which they need to refresh the named resources they know about.  Name
   resolution in such scenarios must take into account link-layer frame
   sizes of only a few hundred bytes, bit rates in the magnitude of
   kilobits per second, and latencies of several seconds [RFC7228]
   [RFC7228bis].

   In order not to be burdened by the resource requirements of TCP and
   HTTPS, constrained IoT devices could use DNS over DTLS [RFC8094].  In
   contrast to DNS over DTLS, DoC can take advantage of CoAP features to
   mitigate drawbacks of datagram-based communication.  These features
   include (1) block-wise transfer [RFC7959], which solves the Path MTU
   problem of DNS over DTLS (see [RFC8094], Section 5), (2) CoAP
   proxies, which provide an additional level of caching, and (3) reuse
   of data structures for application traffic and DNS information, which
   saves memory on constrained devices.

   To avoid the resource requirements of DTLS or TLS on top of UDP
   (e.g., introduced by DNS over DTLS [RFC8094] or DNS over QUIC
   [RFC9250]), DoC allows for lightweight message protection based on
   OSCORE.

              . FETCH coaps://[2001:db8::1]/
             /
            /
          CoAP request
+------+  [DNS query]  +------+------+   DNS query     .--------------.
| DoC  |-------------->| DoC  | DNS  |--- --- --- --->|      DNS       |
|Client|<--------------|Server|Client|<--- --- --- ---| Infrastructure |
+------+ CoAP response +------+------+  DNS response   '--------------'
         [DNS response]
   \                         / \                                    /
    '-----DNS over CoAP-----'   '----DNS over UDP/HTTPS/QUIC/...---'

                   Figure 1: Basic DoC Architecture

   The most important components of DoC can be seen in Figure 1: a DoC
   client tries to resolve DNS information by sending DNS queries
   carried within CoAP requests to a DoC server.  That DoC server can be
   the authoritative name server for the queried record or a DNS client
   (i.e., a stub or recursive resolver) that resolves DNS information by
   using other DNS transports such as DNS over UDP [STD13], DNS over
   HTTPS [RFC8484], or DNS over QUIC [RFC9250] when communicating with
   the upstream DNS infrastructure.  Using that information, the DoC
   server then replies to the queries of the DoC client with DNS
   responses carried within CoAP responses.  A DoC server MAY also serve
   as a DNSSEC validator to provide DNSSEC validation to the more
   constrained DoC clients.

   Note that this specification is distinct from DoH because the CoAP-
   specific FETCH method [RFC8132] is used.  A benefit of using this
   method is having the DNS query in the body such as when using the
   POST method, but with the same caching advantages of responses to
   requests that use the GET method.  Having the DNS query in the body
   means that there is no need for extra base64 encoding, which would
   increase code complexity and message sizes.  Also, this allows for
   the block-wise transfer of queries [RFC7959].