3. Selection of a DoC Server
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
3. Selection of a DoC Server
While there is no path specified for the DoC resource, it is
RECOMMENDED to use the root path "/" to keep the CoAP requests small.
The DoC client needs to know the DoC server and the DoC resource at
the DoC server. Possible options to assure this could be (1) manual
configuration of a Uniform Resource Identifier (URI) [RFC3986] or
Constrained Resource Identifier (CRI) [CRI] or (2) automatic
configuration, e.g., using a CoRE resource directory [RFC9176], DHCP
or Router Advertisement options [RFC9463], or discovery of designated
resolvers [RFC9462]. Automatic configuration MUST only be done from
a trusted source.
3.1. Discovery by Resource Type
For discovery of the DoC resource through a link mechanism that
allows describing a resource type (e.g., the Resource Type attribute
in [RFC6690]), this document introduces the resource type "core.dns".
It can be used to identify a generic DNS resolver that is available
to the client.
3.2. Discovery Using SVCB Resource Records or DNR
A DoC server can also be discovered using Service Binding (SVCB)
Resource Records (RRs) [RFC9460] [RFC9461] resolved via another DNS
service (e.g., provided by an unencrypted local resolver) or
Discovery of Network-designated Resolvers (DNR) Service Parameters
[RFC9463] via DHCP or Router Advertisements. [RFC8323] defines the
Application-Layer Protocol Negotiation (ALPN) ID for CoAP over TLS
servers and [RFC9952] defines the ALPN ID for CoAP over DTLS servers.
DoC servers that use only OSCORE [RFC8613] and Ephemeral Diffie-
Hellman Over COSE (EDHOC) [RFC9528] (COSE stands for "Concise Binary
Object Notation (CBOR) Object Signing and Encryption" [RFC9052]) to
support security cannot be discovered using these SVCB RR or DNR
mechanisms. Specifying an alternate discovery mechanism is out of
the scope of this document.
This document is not an SVCB mapping document for the CoAP schemes as
defined in Section 2.4.3 of [RFC9460]. A full SVCB mapping is
specified in [TRANSPORT-IND]. It generalizes mechanisms for all CoAP
services. This document introduces only the discovery of DoC
services.
This document specifies "docpath" as a single-valued Service
Parameter Key (SvcParamKey) that is mandatory for DoC SVCB records.
If the "docpath" SvcParamKey is absent, the service should not be
considered a valid DoC service.
The docpath is divided up into segments of the absolute path to the
DoC resource (docpath-segment), each a sequence of 1-255 octets. In
ABNF [RFC5234]:
docpath-segment = 1*255OCTET
Note that this restricts the length of each docpath-segment to at
most 255 octets. Paths with longer segments cannot be advertised
with the "docpath" SvcParam and are thus NOT RECOMMENDED for the path
to the DoC resource.
The presentation format value of "docpath" SHALL be a comma-separated
list (Appendix A.1 of [RFC9460]) of 0 or more docpath-segments. The
root path "/" is represented by 0 docpath-segments, i.e., an empty
list. The same considerations apply for the "," and "\" characters
in docpath-segments for zone-file implementations and the alpn-ids in
an "alpn" SvcParam (Section 7.1.1 of [RFC9460]).
The wire-format value for "docpath" consists of 0 or more sequences
of octets prefixed by their respective length as a single octet. We
call this single octet the length octet. The length octet and the
corresponding sequence form a length-value pair. These length-value
pairs are concatenated to form the SvcParamValue. These pairs MUST
exactly fill the SvcParamValue; otherwise, the SvcParamValue is
malformed. Each such length-value pair represents one segment of the
absolute path to the DoC resource. The root path "/" is represented
by 0 length-value pairs, i.e., SvcParamValue length 0.
Note that this format uses the same encoding as the "alpn" SvcParam,
and it can reuse the decoders and encoders for that SvcParam with the
adaption that a length of zero is allowed. As long as each docpath-
segment has a length between 0 and 23 octets, inclusive, it is easily
transferred into the path representation in CRIs [CRI] by masking
each length octet with the CBOR text string major type 3 (0x60 as an
octet; see [RFC8949]). Furthermore, it is easily transferable into a
sequence of CoAP Uri-Path options by mapping each length octet into
the Option Delta and Option Length of the corresponding CoAP Uri-Path
option, provided the docpath-segments are all of a length between 0
and 12 octets (see [RFC7252], Section 3.1). Likewise, it can be
transferred into a URI path-abempty form by replacing each length
octet with the "/" character. None of the abovementioned prevent
longer docpath-segments than the considered ones; they just make the
translation harder as space is required for the longer delimiters,
which in turn require octets to be moved.
To use the service binding from an SVCB RR or DNR Encrypted DNS
option, the DoC client MUST send a DoC request constructed from the
SvcParams including "docpath". The construction algorithm for DoC
requests is as follows, with the provided records in order of their
priority. For the purposes of this algorithm, the DoC client is
assumed to be SVCB-optional (see Section 3 of [RFC9460]).
* If the "alpn" SvcParam value for the service is "coap", a CoAP
request for CoAP over TLS MUST be constructed [RFC8323]. If it is
"co", a CoAP request for CoAP over DTLS MUST be constructed
[RFC9952]. Any other SvcParamKeys specifying a transport are out
of the scope of this document.
* The destination address for the request SHOULD be taken from
additional information about the target. This may include (1) A
or AAAA RRs associated with the target name and delivered with the
SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams
from the SVCB RR (see [RFC9461]), or (3) IPv4 or IPv6 addresses
provided if DNR [RFC9463] is used. As a fallback, an address MAY
be queried for the target name of the SVCB record from another DNS
service.
* The destination port for the request MUST be taken from the "port"
SvcParam value, if present. Otherwise, take the default port of
the CoAP transport, e.g., with regards to this specification, the
default is TCP port 5684 for "coap" or UDP port 5684 for "co".
This document introduces no limitations on the ports that can be
used. If a malicious SVCB record allows its originator to
influence message payloads, Section 12 of [RFC9460] recommends
placing such restrictions in the SVCB mapping document. The
records used in this document only influence the Uri-Path option.
That option is only sent in the plaintext of an encrypted (D)TLS
channel and thus does not warrant any limitations.
* The request URI's hostname component MUST be the Authentication
Domain Name (ADN) when obtained through DNR and MUST be the target
name of the SVCB record when obtained through a _dns query (if
AliasMode is used to the target name of the AliasMode record).
This can be achieved efficiently by setting that name in TLS
Server Name Indication (SNI) [RFC8446] or by setting the Uri-Host
option on each request.
* For each element in the CBOR sequence of the "docpath" SvcParam
value, a Uri-Path option MUST be added to the request.
* If the request constructed this way receives a response, the same
SVCB record MUST be used for construction of future DoC queries.
If not, or if the endpoint becomes unreachable, the algorithm
repeats with the SVCB RR or DNR Encrypted DNS option with the next
highest Service Priority as a fallback (see Sections 2.4.1 and 3
of [RFC9460]).
A more generalized construction algorithm for any CoAP request can be
found in [TRANSPORT-IND].
3.2.1. Examples
A typical SVCB resource record response for a DoC server at the root
path "/" of the server looks like the following (the "docpath"
SvcParam is the last 4 bytes 00 0a 00 00 in the binary):
Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 06 28 00 1e 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 03 02 63 6f 00 0a 00 00
Resource record (human-readable):
_dns.example.org. 1576 IN SVCB 1 dns.example.org (
alpn=co docpath )
The root path is RECOMMENDED but not required. Here are two examples
where the "docpath" represents paths of varying depth. First, "/dns"
is provided in the following example (the last 8 bytes 00 0a 00 04 03
64 6e 73):
Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 00 55 00 22 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 03 02 63 6f 00 0a 00 04 03 64 6e 73
Resource record (human-readable):
_dns.example.org. 85 IN SVCB 1 dns.example.org (
alpn=co docpath=dns )
Second, see an example for the path "/n/s" (the last 8 bytes 00 0a 00
04 01 6e 01 73):
Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 06 6b 00 22 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 03 02 63 6f 00 0a 00 04 01 6e 01 73
Resource record (human-readable):
_dns.example.org. 1643 IN SVCB 1 dns.example.org (
alpn=co docpath=n,s )
If the server also provides DNS over HTTPS, "dohpath" and "docpath"
MAY coexist:
Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 01 ad 00 2c 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 06 02 68 33 02 63 6f 00 07 00 07 2f 7b 3f
64 6e 73 7d 00 0a 00 00
Resource record (human-readable):
_dns.example.org. 429 IN SVCB 1 dns.example.org (
alpn=h3,co dohpath=/{?dns} docpath )