Skip to main content

2. Terminology and Conventions

This section preserves the RFC text for DNS over CoAP, including CoAP FETCH exchanges, application/dns-message Content-Format 553, SVCB docpath discovery, OSCORE and (D)TLS protection, CoAP caching, IANA registrations, and operational/security considerations.

Original RFC Text​

2.  Terminology and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   A server that provides the service specified in this document is
   called a "DoC server" to differentiate it from a classic "DNS
   server".  A DoC server acts as either a DNS stub resolver or a DNS
   recursive resolver [BCP219].  As such, the DoC server communicates
   with an "upstream DNS infrastructure" or a single "upstream DNS
   server".  A "DoC resource" is a CoAP resource [RFC7252] at the DoC
   server that DoC clients can target in order to send a DNS query in a
   CoAP request.

   A client using the service specified in this document to retrieve the
   DNS information is called a "DoC client".

   The term "constrained nodes" is used as defined in [RFC7228].
   [RFC6690] describes that Constrained RESTful Environments (CoRE)
   realize the Representational State Transfer (REST) architecture
   [REST] in a suitable form for such constrained nodes.

   A DoC server can provide Observe capabilities as defined in
   [RFC7641], Section 1.2.  As part of that, it administers a "list of
   observers".  DoC clients using these capabilities are "observers" as
   defined in [RFC7641], Section 1.2.  A "notification" is a CoAP
   response message with an Observe option; see [RFC7641], Section 4.2.

   The terms "payload" and "body" are used as defined in [RFC7959],
   Section 2.  Note that, when block-wise transfer is not used, the
   terms "payload" and "body" are to be understood as equal.

   In the examples in this document, the binary payload and resource
   records are shown in a hexadecimal representation as well as a human-
   readable format for better readability.  However, in the actual
   message sent and received, they are encoded in the binary message
   format defined in [STD13].