rfc9953v1.md   rfc9953.md 
--- ---
title: "DNS over the Constrained Application Protocol (DoC)" title: "DNS over CoAP (DoC)"
abbrev: DoC abbrev: DoC
docname: draft-ietf-core-dns-over-coap-20 docname: draft-ietf-core-dns-over-coap-20
number: 9953 number: 9953
ipr: trust200902 ipr: trust200902
lang: en lang: en
consensus: true consensus: true
obsoletes: obsoletes:
updates: updates:
pi: [toc, symrefs, sortrefs] pi: [toc, symrefs, sortrefs]
category: std category: std
skipping to change at line 122 skipping to change at line 122
RFC9076: dns-privacy RFC9076: dns-privacy
RFC9176: core-rd RFC9176: core-rd
RFC9250: doq RFC9250: doq
RFC9528: edhoc RFC9528: edhoc
I-D.ietf-core-href: I-D.ietf-core-href:
display: CRI display: CRI
I-D.ietf-core-transport-indication: I-D.ietf-core-transport-indication:
display: TRANSPORT-IND display: TRANSPORT-IND
I-D.ietf-iotops-7228bis: I-D.ietf-iotops-7228bis:
display: RFC7228bis display: RFC7228bis
I-D.amsuess-core-cachable-oscore: I-D.ietf-core-cacheable-oscore:
display: CACHABLE-OSCORE display: CACHEABLE-OSCORE
DoC-paper: DoC-paper:
seriesinfo: seriesinfo:
DOI: 10.1145/3609423 DOI: 10.1145/3609423
title: 'Securing Name Resolution in the IoT: DNS over CoAP' title: 'Securing Name Resolution in the IoT: DNS over CoAP'
author: author:
- name: Martine S. Lenders - name: Martine S. Lenders
ins: M. Lenders ins: M. S. Lenders
org: TU Dresden, Germany org: TU Dresden, Germany
- name: Christian Amsüss - name: Christian Amsüss
ins: C. Amsüss ins: C. Amsüss
org: Unaffiliated, Vienna, Austria org: Unaffiliated, Vienna, Austria
- name: Cenk Gündogan - name: Cenk Gündogan
ins: C. Gündogan ins: C. Gündogan
org: Huawei Technologies, Munich, Germany org: Huawei Technologies, Munich, Germany
- name: Marcin Nawrocki - name: Marcin Nawrocki
ins: M. Nawrocki ins: M. Nawrocki
org: TU Dresden, Germany org: TU Dresden, Germany
skipping to change at line 170 skipping to change at line 170
"Ph.D. Dissertation, University of California, Irvine" "Ph.D. Dissertation, University of California, Irvine"
format: format:
HTML: https://ics.uci.edu/~fielding/pubs/dissertation/top.htm HTML: https://ics.uci.edu/~fielding/pubs/dissertation/top.htm
PDF: https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation. pdf PDF: https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation. pdf
--- abstract --- abstract
<!--[rfced] FYI: We updated [I-D.ietf-core-coap-dtls-alpn] to [PRE-RFC9952] <!--[rfced] FYI: We updated [I-D.ietf-core-coap-dtls-alpn] to [PRE-RFC9952]
for now. We will make the final updates in RFCXML (i.e., remove "PRE-"). for now. We will make the final updates in RFCXML (i.e., remove "PRE-").
--> -->
<!--[rfced] Please note that the title of the document has been
updated as follows. The abbreviation has been expanded per Section 3.6
of RFC 7322 ("RFC Style Guide"). We also added "the". Please review.
Original:
DNS over CoAP (DoC)
Current:
DNS over the Constrained Application Protocol (DoC)
<!--[rfced] May we remove "(CoAPS)" in the Abstract as this
term/abbreviation is not used elsewhere in the document? Please
review.
Original:
These CoAP messages can be protected by (D)TLS-Secured CoAP (CoAPS)
or Object Security for Constrained RESTful Environments (OSCORE) to
provide encrypted DNS message exchange for constrained devices in
the Internet of Things (IoT).
Perhaps:
These CoAP messages can be protected by (D)TLS-Secured CoAP or
Object Security for Constrained RESTful Environments (OSCORE) to
provide encrypted DNS message exchange for constrained devices in
the Internet of Things (IoT).
This document defines a protocol for exchanging DNS queries (OPCODE 0) over the This document defines a protocol for exchanging DNS queries (OPCODE 0) over the
Constrained Application Protocol (CoAP). These CoAP messages can be protected Constrained Application Protocol (CoAP). These CoAP messages can be protected
by (D)TLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful by (D)TLS-Secured CoAP or Object Security for Constrained RESTful
Environments (OSCORE) to provide encrypted DNS message exchange for Environments (OSCORE) to provide encrypted DNS message exchange for
constrained devices in the Internet of Things (IoT). constrained devices in the Internet of Things (IoT).
--- middle --- middle
Introduction Introduction
============ ============
This document defines DNS over CoAP (DoC), a protocol to send DNS This document defines DNS over CoAP (DoC), a protocol to send DNS
{{-dns}} queries and get DNS responses over the Constrained Application {{-dns}} queries and get DNS responses over the Constrained Application
Protocol (CoAP) {{-coap}} using OPCODE 0 (Query). Each DNS query-response pair is map ped into a Protocol (CoAP) {{-coap}} using OPCODE 0 (Query). Each DNS query-response pair is map ped into a
CoAP message exchange. Each CoAP message can be secured by DTLS 1.2 or newer {{-dtls1 CoAP message exchange. Each CoAP message can be secured by any combination of DTLS 1.
2}} {{-dtls13}} 2 or newer {{-dtls12}} {{-dtls13}}, TLS 1.3 or newer {{-coap-tcp}} {{?RFC8446}}, or O
as well as Object Security for Constrained RESTful Environments (OSCORE) {{-oscore}} bject Security for Constrained RESTful Environments (OSCORE) {{-oscore}} to ensure me
and TLS 1.3 or newer {{-coap-tcp}} {{?RFC8446}} ssage integrity and confidentiality.
to ensure message integrity and confidentiality.
The application use case of DoC is inspired by DNS over HTTPS (DoH) {{-doh}}. The application use case of DoC is inspired by DNS over HTTPS (DoH) {{-doh}}.
However, DoC aims for deployment in the constrained Internet of However, DoC aims for deployment in the constrained Internet of
Things (IoT), which usually conflicts with the requirements introduced by Things (IoT), which usually conflicts with the requirements introduced by
HTTPS. HTTPS.
Constrained IoT devices may be restricted in memory, power consumption, Constrained IoT devices may be restricted in memory, power consumption,
link-layer frame sizes, throughput, and latency. They may link-layer frame sizes, throughput, and latency. They may
only have a handful kilobytes of both RAM and ROM. They may sleep for long 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 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 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 frame sizes of only a few hundred bytes, bit rates in the magnitude
of kilobits per second, and latencies of several seconds {{-constr-nodes}} {{I-D.ietf -iotops-7228bis}}. of kilobits per second, and latencies of several seconds {{-constr-nodes}} {{I-D.ietf -iotops-7228bis}}.
<!--[rfced] FYI: draft-ietf-iotops-7228bis has not been published yet
(currently, its IESG state is "I-D Exists"). Thus, we have left
references to RFC 7228 and draft-ietf-iotops-7228bis as is.
Author note:
Please remove the {{-constr-nodes}} reference and replace
it with {{I-D.ietf-iotops-7228bis}} throughout the document in case
{{I-D.ietf-iotops-7228bis}} becomes an RFC before publication.
In order not to be burdened by the resource requirements of TCP and HTTPS, constraine d IoT devices could use DNS over DTLS {{-dodtls}}. In order not to be burdened by the resource requirements of TCP and HTTPS, constraine d IoT devices could use DNS over DTLS {{-dodtls}}.
In contrast to DNS over DTLS, DoC In contrast to DNS over DTLS, DoC
can take advantage of CoAP features to mitigate drawbacks of datagram-based can take advantage of CoAP features to mitigate drawbacks of datagram-based
communication. These features include (1) block-wise transfer {{-coap-blockwise}}, wh ich solves communication. These features include (1) block-wise transfer {{-coap-blockwise}}, wh ich solves
the Path MTU problem of DNS over DTLS (see {{-dodtls, Section 5}}), (2) CoAP the Path MTU problem of DNS over DTLS (see {{-dodtls, Section 5}}), (2) CoAP
proxies, which provide an additional level of caching, and (3) reuse of data proxies, which provide an additional level of caching, and (3) reuse of data
structures for application traffic and DNS information, which saves memory structures for application traffic and DNS information, which saves memory
on constrained devices. on constrained devices.
To avoid the resource requirements of DTLS or TLS on top of UDP (e.g., introduced by DNS over DTLS {{-dodtls}} or DNS over QUIC {{-doq}}), DoC allows for lightweight mess age protection based on OSCORE. To avoid the resource requirements of DTLS or TLS on top of UDP (e.g., introduced by DNS over DTLS {{-dodtls}} or DNS over QUIC {{-doq}}), DoC allows for lightweight mess age protection based on OSCORE.
~~~ aasvg ~~~ aasvg
. FETCH coaps://[2001:db8::1]/ . FETCH coaps://[2001:db8::1]/
/ /
/ /
CoAP request CoAP request
+------+ [DNS query] +------+------+ DNS query .---------------. +------+ [DNS query] +------+------+ DNS query .--------------.
| DoC |---------------->| DoC | DNS |--- --- --- --->| DNS | | DoC |-------------->| DoC | DNS |--- --- --- --->| DNS |
|Client|<----------------|Server|Client|<--- --- --- ---| Infrastructure | |Client|<--------------|Server|Client|<--- --- --- ---| Infrastructure |
+------+ CoAP response +------+------+ DNS response '---------------' +------+ CoAP response +------+------+ DNS response '--------------'
[DNS response] [DNS response]
\ / \ / \ / \ /
'------DNS over CoAP------' '----DNS over UDP/HTTPS/QUIC/...----' '-----DNS over CoAP-----' '----DNS over UDP/HTTPS/QUIC/...---'
~~~ ~~~
{: #fig-overview-arch title="Basic DoC Architecture"} {: #fig-overview-arch title="Basic DoC Architecture"}
<!--[rfced] FYI - We updated "authoritive name server" to "authoritative name
server" to match other usage in this document and in other RFCs.
Original:
That DoC server can be the authoritive 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.
Updated:
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.
The most important components of DoC can be seen in {{fig-overview-arch}}: a DoC The most important components of DoC can be seen in {{fig-overview-arch}}: a DoC
client tries to resolve DNS information by sending DNS queries carried within client tries to resolve DNS information by sending DNS queries carried within
CoAP requests to a DoC server. 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 ot her DNS transports such 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 ot her DNS transports such
as DNS over UDP {{-dns}}, DNS over HTTPS {{-doh}}, or DNS over QUIC {{-doq}} when com municating with the upstream as DNS over UDP {{-dns}}, DNS over HTTPS {{-doh}}, or DNS over QUIC {{-doq}} when com municating with the upstream
DNS infrastructure. DNS infrastructure.
Using that information, the DoC server then replies to the queries of the DoC client with DNS Using that information, the DoC server then replies to the queries of the DoC client with DNS
responses carried within CoAP responses. responses carried within CoAP responses.
A DoC server MAY also serve as a DNSSEC validator to provide DNSSEC validation to the more A DoC server MAY also serve as a DNSSEC validator to provide DNSSEC validation to the more
constrained DoC clients. constrained DoC clients.
skipping to change at line 377 skipping to change at line 317
docpath-segment = 1*255OCTET docpath-segment = 1*255OCTET
~~~ ~~~
Note that this restricts the length of each docpath-segment to at most 255 octets. 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 t hus NOT Paths with longer segments cannot be advertised with the "docpath" SvcParam and are t hus NOT
RECOMMENDED for the path to the DoC resource. RECOMMENDED for the path to the DoC resource.
The presentation format value of "docpath" SHALL be a comma-separated list ({{Appendi x A.1 of -svcb}}) The presentation format value of "docpath" SHALL be a comma-separated list ({{Appendi x A.1 of -svcb}})
of 0 or more docpath-segments. of 0 or more docpath-segments.
The root path "/" is represented by 0 docpath-segments, i.e., an empty list. 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 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 -svcb}}). implementations and the alpn-ids in an "alpn" SvcParam ({{Section 7.1.1 of -svcb}}).
The wire-format value for "docpath" consists of 0 or more sequences of octets prefixe d by their The wire-format value for "docpath" consists of 0 or more sequences of octets prefixe d by their
respective length as a single octet. respective length as a single octet.
We call this single octet the length octet. We call this single octet the length octet.
The length octet and the corresponding sequence form a length-value pair. The length octet and the corresponding sequence form a length-value pair.
These length-value pairs are concatenated to form the SvcParamValue. These length-value pairs are concatenated to form the SvcParamValue.
These pairs MUST exactly fill the SvcParamValue; otherwise, the SvcParamValue is malf ormed. These pairs MUST exactly fill the SvcParamValue; otherwise, the SvcParamValue is malf ormed.
Each such length-value pair represents one segment of the absolute path to the DoC re source. Each such length-value pair represents one segment of the absolute path to the DoC re source.
The root path "/" is represented by 0 length-value pairs, i.e., SvcParamValue length 0. The root path "/" is represented by 0 length-value pairs, i.e., SvcParamValue length 0.
<!-- [rfced] Please clarify "is of length 0 and 24 octets" in this sentence.
Original:
As long as each docpath-
segment is of length 0 and 24 octets, it is easily transferred into
the path representation in CRIs [I-D.ietf-core-href] by masking each
length octet with the CBOR text string major type 3 (0x60 as an
octet, see [RFC8949]).
Perhaps:
As long as each docpath-
segment has a length between 0 and 24 octets, 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]).
<!--[rfced] We are having trouble parsing this sentence. Please let us
know if it can be revised as shown below for clarity.
Original:
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,
they just make the translation harder, as they require to make space
for the longer delimiters, in turn requiring to move octets.
Perhaps:
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.
<!-- [rfced] May we update "going through" to "with" here to improve clarity?
Original:
The construction algorithm for DoC
requests is as follows, going through the provided records in order
of their priority.
Perhaps:
The construction algorithm for DoC
requests is as follows, with the provided records in order
of their priority.
Note that this format uses the same encoding as the "alpn" SvcParam, and it can reuse the 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 al lowed. decoders and encoders for that SvcParam with the adaption that a length of zero is al lowed.
As long as each docpath-segment is of length 0 and 24 octets, it is easily transferre d into the path As long as each docpath-segment has a length between 0 and 23 octets, inclusive, it i s easily transferred into the path
representation in CRIs {{I-D.ietf-core-href}} by masking each length octet with the C BOR text string major type 3 representation in CRIs {{I-D.ietf-core-href}} by masking each length octet with the C BOR text string major type 3
(`0x60` as an octet; see {{-cbor}}). (`0x60` as an octet; see {{-cbor}}).
Furthermore, it is easily transferable into a sequence of CoAP Uri-Path options by 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 correspondin g CoAP Uri-Path mapping each length octet into the Option Delta and Option Length of the correspondin g CoAP Uri-Path
option, provided the docpath-segments are all of a length between 0 and 12 octets (se e {{-coap, option, provided the docpath-segments are all of a length between 0 and 12 octets (se e {{-coap,
Section 3.1}}). Likewise, it can be transferred into a URI path-abempty form by repla Section 3.1}}). Likewise, it can be transferred into a URI path-abempty form by repla
cing each length octet with the "/" character cing each length octet with the "/" character.
None of the abovementioned prevent longer docpath-segments than the considered, they None of the abovementioned prevent longer docpath-segments than the considered ones;
just make the they just make the
translation harder, as they require to make space for the longer delimiters, in turn translation harder as space is required for the longer delimiters, which in turn requ
requiring to move octets. ire octets to be moved.
To use the service binding from an SVCB RR or DNR Encrypted DNS option, the DoC clien t MUST send a DoC request constructed from the SvcParams including "docpath". To use the service binding from an SVCB RR or DNR Encrypted DNS option, the DoC clien t MUST send a DoC request constructed from the SvcParams including "docpath".
The construction algorithm for DoC requests is as follows, going through the provided records in order of their priority. 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 (se e {{Section 3 of -svcb}}). For the purposes of this algorithm, the DoC client is assumed to be SVCB-optional (se e {{Section 3 of -svcb}}).
<!-- [rfced] How may we update the third item in the series for parallel
structure? Would either removing "from" or adding "information" be correct?
Original:
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) from IPv4 or IPv6
addresses provided if DNR [RFC9463] is used.
Perhaps A (cut "from"):
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.
or
Perhaps B (add "information"):
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) information from IPv4 or IPv6
addresses provided if DNR [RFC9463] is used.
- If the "alpn" SvcParam value for the service is "coap", a CoAP request for CoAP ove r TLS MUST be constructed {{-coap-tcp}}. - If the "alpn" SvcParam value for the service is "coap", a CoAP request for CoAP ove r TLS MUST be constructed {{-coap-tcp}}.
If it is "co", a CoAP request for CoAP over DTLS MUST be constructed {{PRE-RFC9952} }. If it is "co", a CoAP request for CoAP over DTLS MUST be constructed {{PRE-RFC9952} }.
Any other SvcParamKeys specifying a transport are out of the scope of this document . 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. - 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 wi th the SVCB RR (see {{-ddr}}), (2) "ipv4hint" or "ipv6hint" SvcParams from the SVCB R R (see {{-svcb-dns}}), or (3) from IPv4 or IPv6 addresses provided if DNR {{-dnr}} is used. This may include (1) A or AAAA RRs associated with the target name and delivered wi th the SVCB RR (see {{-ddr}}), (2) "ipv4hint" or "ipv6hint" SvcParams from the SVCB R R (see {{-svcb-dns}}), or (3) IPv4 or IPv6 addresses provided if DNR {{-dnr}} is used .
As a fallback, an address MAY be queried for the target name of the SVCB record fro m another DNS service. As a fallback, an address MAY be queried for the target name of the SVCB record fro m another DNS service.
- The destination port for the request MUST be taken from the "port" SvcParam value, if present. - 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". 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. This document introduces no limitations on the ports that can be used.
If a malicious SVCB record allows its originator to influence message payloads, {{S ection 12 of -svcb}} recommends placing such restrictions in the SVCB mapping documen t. If a malicious SVCB record allows its originator to influence message payloads, {{S ection 12 of -svcb}} recommends placing such restrictions in the SVCB mapping documen t.
The records used in this document only influence the Uri-Path option. 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 That option is only sent in the plaintext of an encrypted (D)TLS channel
and thus does not warrant any limitations. and thus does not warrant any limitations.
- The request URI's hostname component MUST be the Authentication Domain Name (ADN) w hen obtained through DNR - The request URI's hostname component MUST be the Authentication Domain Name (ADN) w hen obtained through DNR
and MUST be the target name of the SVCB record when obtained through a `_dns` query and MUST be the target name of the SVCB record when obtained through a `_dns` query
skipping to change at line 506 skipping to change at line 371
This can be achieved efficiently by setting that name in TLS Server Name Indication (SNI) {{?RFC8446}} 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. 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 o ption MUST be added to the request. - For each element in the CBOR sequence of the "docpath" SvcParam value, a Uri-Path o ption 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 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 -svcb}}). 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 -svcb}}).
A more generalized construction algorithm for any CoAP request can be found in {{I-D. ietf-core-transport-indication}}. A more generalized construction algorithm for any CoAP request can be found in {{I-D. ietf-core-transport-indication}}.
### Examples ### Examples
<!--[rfced] Per the following note, we have replaced "ff 0a" with "00 0a" in
the examples in Section 3.2.1 (per IANA's assignment of "10" for
"docpath"). Please confirm that this is correct and let us know if any further
updates are needed.
Author note:
Since the number for "docpath" was not assigned at the time of
writing, we used the hex `ff 0a` (in decimal 65290; from the
private use range of SvcParamKeys) throughout this section. Before
publication, please replace `ff 0a` with the hexadecimal
representation of the final value assigned by IANA in this
section. Please remove this paragraph after that.
A typical SVCB resource record response for a DoC server at the root path "/" of the server looks 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 b inary): like the following (the "docpath" SvcParam is the last 4 bytes `00 0a 00 00` in the b inary):
~~~ ~~~
Resource record (binary): Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 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 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 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 01 00 03 02 63 6f 00 0a 00 00
Resource record (human-readable): Resource record (human-readable):
_dns.example.org. 1576 IN SVCB 1 dns.example.org ( _dns.example.org. 1576 IN SVCB 1 dns.example.org (
alpn=co docpath ) alpn=co docpath )
~~~ ~~~
{: gi="sourcecode"} {: gi="sourcecode"}
The root path is RECOMMENDED but not required. Here are two examples where the "docpa th" represents The root path is RECOMMENDED but not required. Here are two examples where the "docpa th" represents
paths of varying depth. First, "/dns" is provided in the following example paths of varying depth. First, "/dns" is provided in the following example
(the last 8 bytes `00 0a 00 04 03 64 6e 73`): (the last 8 bytes `00 0a 00 04 03 64 6e 73`):
~~~ ~~~
Resource record (binary): Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 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 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 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 01 00 03 02 63 6f 00 0a 00 04 03 64 6e 73
Resource record (human-readable): Resource record (human-readable):
_dns.example.org. 85 IN SVCB 1 dns.example.org ( _dns.example.org. 85 IN SVCB 1 dns.example.org (
alpn=co docpath=dns ) alpn=co docpath=dns )
~~~ ~~~
{: gi="sourcecode"} {: gi="sourcecode"}
Second, see an example for the path "/n/s" (the last 8 bytes `00 0a 00 04 01 6e 01 73 `): Second, see an example for the path "/n/s" (the last 8 bytes `00 0a 00 04 01 6e 01 73 `):
~~~ ~~~
Resource record (binary): Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 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 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 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 01 00 03 02 63 6f 00 0a 00 04 01 6e 01 73
Resource record (human-readable): Resource record (human-readable):
_dns.example.org. 643 IN SVCB 1 dns.example.org ( _dns.example.org. 1643 IN SVCB 1 dns.example.org (
alpn=co docpath=n,s ) alpn=co docpath=n,s )
~~~ ~~~
{: gi="sourcecode"} {: gi="sourcecode"}
If the server also provides DNS over HTTPS, "dohpath" and "docpath" MAY coexist: If the server also provides DNS over HTTPS, "dohpath" and "docpath" MAY coexist:
~~~ ~~~
Resource record (binary): Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 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 2b 00 01 03 64 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 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 01 00 06 02 68 33 02 63 6f 00 07 00 07 2f 7b 3f
64 6e 73 7d 00 0a 00 00 64 6e 73 7d 00 0a 00 00
Resource record (human-readable): Resource record (human-readable):
_dns.example.org. 429 IN SVCB 1 dns.example.org ( _dns.example.org. 429 IN SVCB 1 dns.example.org (
alpn=h3,co dohpath=/{?dns} docpath ) alpn=h3,co dohpath=/{?dns} docpath )
~~~ ~~~
{: gi="sourcecode"} {: gi="sourcecode"}
Basic Message Exchange Basic Message Exchange
====================== ======================
The "application/dns-message" Content-Format {#sec:content-format} The "application/dns-message" Content-Format {#sec:content-format}
-------------------------------------------- --------------------------------------------
This document defines a CoAP Content-Format ID for the Internet 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 assign ment of DNS. media type "application/dns-message" to be the mnemonic 553, based on the port assign ment of DNS.
skipping to change at line 615 skipping to change at line 466
DNS protocol as defined in {{-dns}} is not needed. DNS protocol as defined in {{-dns}} is not needed.
### Request Format ### Request Format
When sending a CoAP request, a DoC client MUST include the DNS query in the body of t he CoAP request. When sending a CoAP request, a DoC client MUST include the DNS query in the body of t he CoAP request.
As specified in {{Section 2.3.1 of -coap-fetch}}, the type of content of the body MUS T be indicated using the Content-Format option. As specified in {{Section 2.3.1 of -coap-fetch}}, the type of content of the body MUS T be indicated using the Content-Format option.
This document specifies the usage of Content-Format "application/dns-message" (for de tails, see {{sec:content-format}}). This document specifies the usage of Content-Format "application/dns-message" (for de tails, see {{sec:content-format}}).
### Support of CoAP Caching {#sec:req-caching} ### Support of CoAP Caching {#sec:req-caching}
<!--[rfced] We note that "Cache-Key" appears as "cache key" in RFC
8132. Would you like to match use in RFC 8132?
Original:
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.
Perhaps:
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.
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. 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 {{-coap-fetch, Section 2}}) does not change when multiple DNS queries for the same DNS data, carried in CoAP requests, are issue d. This ensures that the CoAP Cache-Key (see {{-coap-fetch, Section 2}}) does not change when multiple DNS queries for the same DNS data, carried in CoAP requests, are issue d.
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. 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. In any instance, a DoC server MUST copy the ID from the query in its response to that query.
### Example {#sec:req-examples} ### Example {#sec:req-examples}
The following example illustrates the usage of a CoAP message to 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 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. CoAP body is encoded in the "application/dns-message" Content-Format.
~~~ ~~~
FETCH coaps://[2001:db8::1]/ FETCH coaps://[2001:db8::1]/
Content-Format: 553 (application/dns-message) Content-Format: 553 (application/dns-message)
Accept: 553 (application/dns-message) Accept: 553 (application/dns-message)
Payload (binary): Payload (binary):
00 00 01 00 00 01 00 00 00 00 00 00 07 65 78 61 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 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01
Payload (human-readable): Payload (human-readable):
;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0 ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;; QUESTION SECTION:
;example.org. IN AAAA ;example.org. IN AAAA
~~~ ~~~
{: gi="sourcecode"} {: gi="sourcecode"}
DNS Responses in CoAP Responses DNS Responses in CoAP Responses
------------------------------- -------------------------------
Each DNS query-response pair is mapped to a CoAP request-response operation. 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 possibl e to transfer them using block-wise transfer {{-coap-blockwise}}. DNS responses are provided in the body of the CoAP response, i.e., it is also possibl e to transfer them using block-wise transfer {{-coap-blockwise}}.
A DoC server MUST be able to produce responses in the "application/dns-message" A DoC server MUST be able to produce responses in the "application/dns-message"
Content-Format (for details, see {{sec:content-format}}) when requested. Content-Format (for details, see {{sec:content-format}}) when requested.
The use of the Accept option in the request is optional. 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 {{sec:content-format}}). However, all DoC clients MUST be able to parse an "application/dns-message" response (see also {{sec:content-format}}).
Any response Content-Format other than "application/dns-message" MUST be indicated wi th Any response Content-Format other than "application/dns-message" MUST be indicated wi th
the Content-Format option by the DoC server. the Content-Format option by the DoC server.
### Response Codes and Handling DNS and CoAP Errors {#sec:resp-codes} ### Response Codes and Handling DNS and CoAP Errors {#sec:resp-codes}
A DNS response indicates either success or failure in the RCODE of the DNS header (se e {{-dns}}). A DNS response indicates either success or failure in the RCODE of the DNS header (se e {{-dns}}).
It is RECOMMENDED that CoAP responses that carry a parsable DNS response use a 2.05 ( Content) response code. 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 CoAP responses using non-successful response codes MUST NOT contain a DNS response
skipping to change at line 719 skipping to change at line 557
AAAA record", with recursion turned on. Successful responses carry one answer 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. record including the address 2001:db8:1:0:1:2:3:4 and TTL 79689.
A successful response: A successful response:
~~~ ~~~
2.05 Content 2.05 Content
Content-Format: 553 (application/dns-message) Content-Format: 553 (application/dns-message)
Max-Age: 58719 Max-Age: 58719
Payload (human-readable): Payload (human-readable):
;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0 ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;; QUESTION SECTION:
;example.org. IN AAAA ;example.org. IN AAAA
;; ANSWER SECTION: ;; ANSWER SECTION:
;example.org. 79689 IN AAAA 2001:db8:1:0:1:2:3:4 ;example.org. 79689 IN AAAA 2001:db8:1:0:1:2:3:4
~~~ ~~~
{: gi="sourcecode"} {: gi="sourcecode"}
When a DNS error -- NxDomain (RCODE = 3) for "does.not.exist" in this case -- is note d in the DNS response, the CoAP response still indicates success. 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 2.05 Content
Content-Format: 553 (application/dns-message) Content-Format: 553 (application/dns-message)
Payload (human-readable): Payload (human-readable):
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 0 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 0
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;; QUESTION SECTION:
;does.not.exist. IN AAAA ;does.not.exist. IN AAAA
~~~ ~~~
{: gi="sourcecode"} {: gi="sourcecode"}
<!-- [rfced] Please review the text starting with "OPCODE—a DNS As described in {{sec:content-format}}, a DoC server uses NotImp (RCODE = 4) if it do
Update ...". Should this be updated as follows or in some other way? es not support an OPCODE - in this case, it errors on a DNS Update (OPCODE = 5) for "
example.org".
Original:
As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if
it does not support an OPCODE—a DNS Update (OPCODE = 5) for
"example.org" in this case.
Perhaps:
As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if
it does not support an OPCODE - in this case, a DNS Update (OPCODE = 5) for
"example.org" is used.
As described in {{sec:content-format}}, a DoC server uses NotImp (RCODE = 4) if it do
es not support an OPCODE-a DNS Update (OPCODE = 5) for "example.org" in this case.
~~~ ~~~
2.05 Content 2.05 Content
Content-Format: 553 (application/dns-message) Content-Format: 553 (application/dns-message)
Payload (human-readable): Payload (human-readable):
;; ->>Header<<- opcode: UPDATE, status: NOTIMP, id: 0 ;; ->>Header<<- opcode: UPDATE, status: NOTIMP, id: 0
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION: ;; QUERY SECTION:
;example.org. IN AAAA ;example.org. IN AAAA
~~~ ~~~
{: gi="sourcecode"} {: gi="sourcecode"}
When an error occurs at the CoAP layer, the DoC server responds with When an error occurs at the CoAP layer, the DoC server responds with
an appropriate CoAP error, for instance, 4.15 (Unsupported Content-Format) an appropriate CoAP error, for instance, 4.15 (Unsupported Content-Format)
if the Content-Format option in the request was not set to if the Content-Format option in the request was not set to
"application/dns-message" and the Content-Format is not otherwise supported by "application/dns-message" and the Content-Format is not otherwise supported by
the server. the server.
~~~ ~~~
skipping to change at line 797 skipping to change at line 621
--------------------------------------- ---------------------------------------
DNS Push Notifications {{-dns-push}} provide the capability to asynchronously notify clients about resource record changes. DNS Push Notifications {{-dns-push}} provide the capability to asynchronously notify clients about resource record changes.
However, it results in additional overhead, which conflicts with constrained resource s. However, it results in additional overhead, which conflicts with constrained resource s.
This is the reason why it is RECOMMENDED to use CoAP Observe {{-coap-observe}} instea d of DNS Push This is the reason why it is RECOMMENDED to use CoAP Observe {{-coap-observe}} instea d of DNS Push
in the DoC domain. in the DoC domain.
This is particularly useful if a short-lived record is requested frequently. 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 foll ows. The DoC server SHOULD provide Observe capabilities on its DoC resource and do as foll ows.
If a DoC client wants to observe a resource record, a DoC server can respond with a n otification If a DoC client wants to observe a resource record, a DoC server can respond with a n otification
and add the client to its list of observers for that resource in accordance with {{-c oap-observe}}. and add the client to its list of observers for that resource in accordance with {{-c oap-observe}}.
The DoC server MAY subscribe to DNS push notifications for that record. The DoC server MAY subscribe to DNS Push Notifications for that record.
This involves sending a DNS Subscribe message (see {{Section 6.2 of -dns-push}}), This involves sending a DNS Subscribe message (see {{Section 6.2 of -dns-push}}),
instead of a classic DNS query to fetch the instead of a classic DNS query to fetch the
information on behalf of the DoC client. information on behalf of the DoC client.
<!--[rfced] Please clarify what "a failure to do so" refers to in the
following sentence.
Original:
As there is no CoAP observer anymore from the perspective of the
DoC server, a failure to do so cannot be communicated back to any
DoC observer.
After the list of observers for a particular DNS query has become empty 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 -coa p-observe}}), (by explicit or implicit cancellation of the observation as per {{Section 3.6 of -coa p-observe}}),
and no other reason to subscribe to that request is present, and no other reason to subscribe to that request is present,
the DoC server SHOULD cancel the corresponding subscription. the DoC server SHOULD cancel the corresponding subscription.
This can involve sending a DNS Unsubscribe message or closing the session (see {{Sect ion 6.4 of -dns-push}}). This can involve sending a DNS Unsubscribe message or closing the session (see {{Sect ion 6.4 of -dns-push}}).
As there is no CoAP observer anymore from the perspective of the DoC server, a failur e to do so cannot be communicated back to any DoC observer. As there is no CoAP observer anymore from the perspective of the DoC server, a failur e 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. 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 Whenever the DoC server receives a DNS Push message from the DNS
infrastructure for an observed resource record, the DoC server sends an appropriate O bserve notification response infrastructure for an observed resource record, the DoC server sends an appropriate O bserve notification response
to the DoC client. to the DoC client.
A server that responds with notifications (i.e., sends the Observe option) needs to h ave the means of obtaining current resource records. A server that responds with notifications (i.e., sends the Observe option) needs to h ave the means of obtaining current resource records.
This may happen through DNS Push or also by upstream polling or implicit circumstance s (e.g., if the DoC server is the authoritative name server for the record and wants to notify about changes). This may happen through DNS Push or also by upstream polling or implicit circumstance s (e.g., if the DoC server is the authoritative name server for the record and wants to notify about changes).
OSCORE OSCORE
------ ------
It is RECOMMENDED to carry DNS messages protected using OSCORE {{-oscore}} between th e DoC client It is RECOMMENDED to carry DNS messages protected using OSCORE {{-oscore}} between th e DoC client
and the DoC server. The establishment and maintenance of the OSCORE security context is out of the and the DoC server. The establishment and maintenance of the OSCORE security context is out of the
scope of this document. scope of this document.
{{I-D.amsuess-core-cachable-oscore}} describes a method to allow cache retrieval of O SCORE responses and discusses {{I-D.ietf-core-cacheable-oscore}} describes a method to allow cache retrieval of OSC ORE responses and discusses
the corresponding implications on message sizes and security properties. the corresponding implications on message sizes and security properties.
Mapping DoC to DoH 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: 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 ({{sec:queries}}) and TTL ({{sec:resp-caching}}) as Rewriting the FETCH method ({{sec:queries}}) and TTL ({{sec:resp-caching}}) as
specified in this document would be non-trivial. 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 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. mapping between any other pair of DNS transports.
skipping to change at line 859 skipping to change at line 674
While DoC does not use the random ID of the DNS header (see {{sec:req-caching}}), equ ivalent protection against off-path poisoning attacks is achieved by using random lar ge token values for unprotected CoAP requests. While DoC does not use the random ID of the DNS header (see {{sec:req-caching}}), equ ivalent protection against off-path poisoning attacks is achieved by using random lar ge token values for unprotected CoAP requests.
If a DoC message is unprotected, it MUST use a random token with a length of at least 2 bytes to mitigate this kind of poisoning attack. If a DoC message is unprotected, it MUST use a random token with a length of at least 2 bytes to mitigate this kind of poisoning attack.
Security Considerations Security Considerations
======================= =======================
General CoAP security considerations ({{RFC7252, Section 11}}) apply to DoC. General CoAP security considerations ({{RFC7252, Section 11}}) apply to DoC.
DoC also inherits the security considerations of the protocols used for secure commun ication, e.g., OSCORE ({{-oscore, Section 12}}) as well as DTLS 1.2 or newer ({{-dtls 12, Section 5}} and {{-dtls13, Section 11}}). DoC also inherits the security considerations of the protocols used for secure commun ication, e.g., OSCORE ({{-oscore, Section 12}}) as well as DTLS 1.2 or newer ({{-dtls 12, Section 5}} and {{-dtls13, Section 11}}).
Additionally, DoC uses request patterns that require the maintenance of long-lived se curity Additionally, DoC uses request patterns that require the maintenance of long-lived se curity
contexts. contexts.
{{Section 2.6 of I-D.ietf-core-corr-clar}} provides insights on what can be done when those are resumed from a new endpoint. {{Section 2.7 of I-D.ietf-core-corr-clar}} provides insights on what can be done when those are resumed from a new endpoint.
Though DTLS v1.2 {{-dtls12}} was obsoleted by DTLS v1.3 {{-dtls13}}, there are many C oAP Though DTLS v1.2 {{-dtls12}} was obsoleted by DTLS v1.3 {{-dtls13}}, there are many C oAP
implementations that still use v1.2 at the time of writing. implementations that still use v1.2 at the time of writing.
As such, this document also accounts for the usage of DTLS v1.2 even though newer ver sions are As such, this document also accounts for the usage of DTLS v1.2 even though newer ver sions are
RECOMMENDED when using DTLS to secure CoAP. RECOMMENDED when using DTLS to secure CoAP.
When using unprotected CoAP (see {{sec:unprotected-coap}}), setting the ID of a DNS m essage to 0 as When using unprotected CoAP (see {{sec:unprotected-coap}}), setting the ID of a DNS m essage to 0 as
specified in {{sec:req-caching}} opens the DNS cache of a DoC client to cache poisoni ng attacks specified in {{sec:req-caching}} opens the DNS cache of a DoC client to cache poisoni ng attacks
via response spoofing. via response spoofing.
This document requires an unpredictable CoAP token in each DoC query from the client when CoAP is This document requires an unpredictable CoAP token in each DoC query from the client when CoAP is
not secured to mitigate such an attack over DoC (see {{sec:unprotected-coap}}). not secured to mitigate such an attack over DoC (see {{sec:unprotected-coap}}).
<!--[rfced] FYI: We added "to protect" to this sentence for
clarity. Please let us know if it changes the intended meaning.
Original:
For secure communication via (D)TLS or OSCORE, an unpredictable ID
against spoofing is not necessary.
Updated:
For secure communication via (D)TLS or OSCORE, an unpredictable ID
to protect against spoofing is not necessary.
For secure communication via (D)TLS or OSCORE, an unpredictable ID to protect against spoofing is not necessary. For secure communication via (D)TLS or OSCORE, an unpredictable ID to protect against spoofing is not necessary.
Both (D)TLS and OSCORE offer mechanisms to harden against injecting spoofed responses in their protocol design. Both (D)TLS and OSCORE offer mechanisms to harden against injecting spoofed responses in their protocol design.
Consequently, the ID of the DNS message can be set to 0 without any concern in order to leverage the advantages of CoAP caching. Consequently, the ID of the DNS message can be set to 0 without any concern in order to leverage the advantages of CoAP caching.
A DoC client must be aware that the DoC server A DoC client must be aware that the DoC server
may communicate unprotected with the upstream DNS infrastructure, e.g., using DNS ove r UDP. may communicate unprotected with the upstream DNS infrastructure, e.g., using DNS ove r UDP.
DoC can only guarantee confidentiality and integrity of communication between parties for which the DoC can only guarantee confidentiality and integrity of communication between parties for which the
security context is exchanged. security context is exchanged.
The DoC server may use another security context to communicate upstream with both con fidentiality and integrity The DoC server may use another security context to communicate upstream with both con fidentiality and integrity
(e.g., DNS over QUIC {{-doq}}); however, while recommended, this is opaque to the DoC client on the protocol level. (e.g., DNS over QUIC {{-doq}}); however, while recommended, this is opaque to the DoC client on the protocol level.
skipping to change at line 986 skipping to change at line 789
DNS extensions that are specific to the choice of transport, such as described in {{? RFC7828}}, are not applicable to DoC. DNS extensions that are specific to the choice of transport, such as described in {{? RFC7828}}, are not applicable to DoC.
--- back --- back
Evaluation {#sec:evaluation} Evaluation {#sec:evaluation}
========== ==========
The authors of this document presented the design, implementation, and analysis of Do C in their The authors of this document presented the design, implementation, and analysis of Do C in their
paper "Securing Name Resolution in the IoT: DNS over CoAP" {{DoC-paper}}. paper "Securing Name Resolution in the IoT: DNS over CoAP" {{DoC-paper}}.
<!-- [rfced] FYI: We removed the change log, which included a
reference to RFC 2136. If RFC 2136 should be mentioned elsewhere in
the running text, please let us know.
<!--[rfced] We note that "draft-amsuess-core-cachable-oscore" is
expired and has been replaced by "draft-ietf-core-cacheable-oscore".
May we replace the current entry below with the entry for
"draft-ietf-core-cacheable-oscore"?
Current:
[I-D.amsuess-core-cachable-oscore]
Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in Progress,
Internet-Draft, draft-amsuess-core-cachable-oscore-11, 6 July 2025,
<https://datatracker.ietf.org/doc/html/draft-amsuess-core-cachable-
oscore-11>.
Perhaps:
[CACHABLE-OSCORE]
Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in
Progress, Internet-Draft, draft-ietf-core-cacheable-
oscore-00, 22 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
cacheable-oscore-00>.
<!--[rfced] Sourcecode and artwork <!--[rfced] Sourcecode and artwork
a) Some lines in Figure 1 are too long for the TXT output. This figure is
marked as artwork, so it needs to have a width of 72 characters or less. How
may we revise this figure to fit these parameters? We tested removing some
space in the figure; please check out the following test files and let us know
if this would work (see TXT file for ascii art and HTML for SVG). If not, please
provide an updated figure.
Test files:
https://www.rfc-editor.org/authors/rfc9953test.md
https://www.rfc-editor.org/authors/rfc9953test.txt
https://www.rfc-editor.org/authors/rfc9953test.html
b) We have updated the blocks in Sections 3.2, 3.2.1, 4.2.3, and 4.3.3 to be
marked as sourcecode. We set the type for the block in Section 3.2 as "abnf"
(i.e., "~~~ abnf"). Please let us know if the type should be set for the other
sourcecode blocks. For example, should the ones in Section 3.2.1 be marked as
type "dns-rr"? If the current list of preferred values (see link below) does
not contain an applicable type, feel free to let us know. Also, it is
acceptable to leave the type not set.
List of sourcecode types:
https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types
c) The blocks in Section 4.3.3 are too long for the TXT output. We marked c) The blocks in Section 4.3.3 are too long for the TXT output. We marked
these as sourcecode, so they should have a width of 69 characters or less. The these as sourcecode, so they should have a width of 69 characters or less. The
long lines are currently 70 characters. Would moving all the lines with long lines are currently 70 characters. Would moving all the lines with
semicolons over to the left one space (in just this section or in all the semicolons over to the left one space (in just this section or in all the
sourcecode in the document) be a good solution? We tried this in the test sourcecode in the document) be a good solution? We tried this in the test
files listed above so you can see what the output will look like. Feel free to files listed above so you can see what the output will look like. Feel free to
offer other suggestions as well. offer other suggestions as well.
--> -->
<!--[rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
# Acknowledgments # Acknowledgments
{:unnumbered} {:unnumbered}
The authors of this document want to thank {{{Mike Bishop}}}, {{{Carsten Bormann}}}, {{{Mohamed Boucadair}}}, {{{Deb Cooley}}}, {{{Vladimír Čunát}}}, {{{Roman Danyliw}}}, {{{Elwyn B. Davies}}}, {{{Esko Dijk}}}, {{{Gorry Fairhurst}}}, {{{Thomas Fossati}}}, {{{Mikolai Gütschow}}}, {{{Todd Herr}}}, {{{Tommy Pauly}}}, {{{Jan Romann}}}, {{{Ben Schwartz}}}, {{{Orie Steele}}}, {{{Marco Tiloca}}}, {{{Éric Vyncke}}}, {{{Tim Wicins ki}}}, and {{{Paul Wouters}}} for their feedback and comments. The authors of this document want to thank {{{Mike Bishop}}}, {{{Carsten Bormann}}}, {{{Mohamed Boucadair}}}, {{{Deb Cooley}}}, {{{Vladimír Čunát}}}, {{{Roman Danyliw}}}, {{{Elwyn B. Davies}}}, {{{Esko Dijk}}}, {{{Gorry Fairhurst}}}, {{{Thomas Fossati}}}, {{{Mikolai Gütschow}}}, {{{Todd Herr}}}, {{{Tommy Pauly}}}, {{{Jan Romann}}}, {{{Ben Schwartz}}}, {{{Orie Steele}}}, {{{Marco Tiloca}}}, {{{Éric Vyncke}}}, {{{Tim Wicins ki}}}, and {{{Paul Wouters}}} for their feedback and comments.
This work was supported in parts by the German Federal Ministry of Research, Technolo
gy and Space (BMFTR) under the grant numbers 16KIS1386K (TU Dresden) and 16KIS1387 (H
AW Hamburg) within the research project PIVOT and under the grant numbers 16KIS1694K
(TU Dresden) and 16KIS1695 (HAW Hamburg) within the research project C-ray4edge.
[draft-ietf-core-dns-over-coap-18]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-18 [draft-ietf-core-dns-over-coap-18]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-18
[draft-ietf-core-dns-over-coap-17]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-17 [draft-ietf-core-dns-over-coap-17]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-17
[draft-ietf-core-dns-over-coap-16]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-16 [draft-ietf-core-dns-over-coap-16]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-16
[draft-ietf-core-dns-over-coap-15]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-15 [draft-ietf-core-dns-over-coap-15]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-15
[draft-ietf-core-dns-over-coap-14]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-14 [draft-ietf-core-dns-over-coap-14]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-14
[draft-ietf-core-dns-over-coap-13]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-13 [draft-ietf-core-dns-over-coap-13]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-13
[draft-ietf-core-dns-over-coap-12]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-12 [draft-ietf-core-dns-over-coap-12]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-12
[draft-ietf-core-dns-over-coap-10]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-10 [draft-ietf-core-dns-over-coap-10]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-10
[draft-ietf-core-dns-over-coap-09]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-09 [draft-ietf-core-dns-over-coap-09]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-09
[draft-ietf-core-dns-over-coap-08]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-08 [draft-ietf-core-dns-over-coap-08]: https://datatracker.ietf.org/doc/html/draft-ietf- core-dns-over-coap-08
 End of changes. 48 change blocks. 
317 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.48.