rfc9953v1.txt		rfc9953.txt
	skipping to change at line 14 ¶		skipping to change at line 14 ¶
	Category: Standards Track C. Amsüss		Category: Standards Track C. Amsüss
	ISSN: 2070-1721		ISSN: 2070-1721
	C. Gündoğan		C. Gündoğan
	NeuralAgent GmbH		NeuralAgent GmbH
	T. C. Schmidt		T. C. Schmidt
	HAW Hamburg		HAW Hamburg
	M. Wählisch		M. Wählisch
	TU Dresden & Barkhausen Institut		TU Dresden & Barkhausen Institut
	March 2026		March 2026
	DNS over the Constrained Application Protocol (DoC)		DNS over CoAP (DoC)
	Abstract		Abstract
	This document defines a protocol for exchanging DNS queries (OPCODE		This document defines a protocol for exchanging DNS queries (OPCODE
	0) over the Constrained Application Protocol (CoAP). These CoAP		0) over the Constrained Application Protocol (CoAP). These CoAP
	messages can be protected by (D)TLS-Secured CoAP (CoAPS) or Object		messages can be protected by (D)TLS-Secured CoAP or Object Security
	Security for Constrained RESTful Environments (OSCORE) to provide		for Constrained RESTful Environments (OSCORE) to provide encrypted
	encrypted DNS message exchange for constrained devices in the		DNS message exchange for constrained devices in the Internet of
	Internet of Things (IoT).		Things (IoT).
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 101 ¶		skipping to change at line 101 ¶
	Appendix A. Evaluation		Appendix A. Evaluation
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. 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
	[STD13] queries and get DNS responses over the Constrained		[STD13] queries and get DNS responses over the Constrained
	Application Protocol (CoAP) [RFC7252] using OPCODE 0 (Query). Each		Application Protocol (CoAP) [RFC7252] using OPCODE 0 (Query). Each
	DNS query-response pair is mapped into a CoAP message exchange. Each		DNS query-response pair is mapped into a CoAP message exchange. Each
	CoAP message can be secured by DTLS 1.2 or newer [RFC6347] [RFC9147]		CoAP message can be secured by any combination of DTLS 1.2 or newer
	as well as Object Security for Constrained RESTful Environments		[RFC6347] [RFC9147], TLS 1.3 or newer [RFC8323] [RFC8446], or Object
	(OSCORE) [RFC8613] and TLS 1.3 or newer [RFC8323] [RFC8446] to ensure		Security for Constrained RESTful Environments (OSCORE) [RFC8613] to
	message integrity and confidentiality.		ensure message integrity and confidentiality.
	The application use case of DoC is inspired by DNS over HTTPS (DoH)		The application use case of DoC is inspired by DNS over HTTPS (DoH)
	[RFC8484]. However, DoC aims for deployment in the constrained		[RFC8484]. However, DoC aims for deployment in the constrained
	Internet of Things (IoT), which usually conflicts with the		Internet of Things (IoT), which usually conflicts with the
	requirements introduced by HTTPS. Constrained IoT devices may be		requirements introduced by HTTPS. Constrained IoT devices may be
	restricted in memory, power consumption, link-layer frame sizes,		restricted in memory, power consumption, link-layer frame sizes,
	throughput, and latency. They may only have a handful kilobytes of		throughput, and latency. They may only have a handful kilobytes of
	both RAM and ROM. They may sleep for long durations of time, after		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		which they need to refresh the named resources they know about. Name
	resolution in such scenarios must take into account link-layer frame		resolution in such scenarios must take into account link-layer frame
	skipping to change at line 137 ¶		skipping to change at line 137 ¶
	saves memory on constrained devices.		saves memory on constrained devices.
	To avoid the resource requirements of DTLS or TLS on top of UDP		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		(e.g., introduced by DNS over DTLS [RFC8094] or DNS over QUIC
	[RFC9250]), DoC allows for lightweight message protection based on		[RFC9250]), DoC allows for lightweight message protection based on
	OSCORE.		OSCORE.
	. 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/...---'
	Figure 1: Basic DoC Architecture		Figure 1: Basic DoC Architecture
	The most important components of DoC can be seen in Figure 1: a DoC		The most important components of DoC can be seen in Figure 1: a DoC
	client tries to resolve DNS information by sending DNS queries		client tries to resolve DNS information by sending DNS queries
	carried within CoAP requests to a DoC server. That DoC server can be		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		the authoritative name server for the queried record or a DNS client
	(i.e., a stub or recursive resolver) that resolves DNS information by		(i.e., a stub or recursive resolver) that resolves DNS information by
	using other DNS transports such as DNS over UDP [STD13], DNS over		using other DNS transports such as DNS over UDP [STD13], DNS over
	HTTPS [RFC8484], or DNS over QUIC [RFC9250] when communicating with		HTTPS [RFC8484], or DNS over QUIC [RFC9250] when communicating with
	skipping to change at line 274 ¶		skipping to change at line 274 ¶
	docpath-segment = 1*255OCTET		docpath-segment = 1*255OCTET
	Note that this restricts the length of each docpath-segment to at		Note that this restricts the length of each docpath-segment to at
	most 255 octets. Paths with longer segments cannot be advertised		most 255 octets. Paths with longer segments cannot be advertised
	with the "docpath" SvcParam and are thus NOT RECOMMENDED for the path		with the "docpath" SvcParam and are thus NOT RECOMMENDED for the path
	to the DoC resource.		to the DoC resource.
	The presentation format value of "docpath" SHALL be a comma-separated		The presentation format value of "docpath" SHALL be a comma-separated
	list (Appendix A.1 of [RFC9460]) of 0 or more docpath-segments. The		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		root path "/" is represented by 0 docpath-segments, i.e., an empty
	list. The same considerations apply for the "," and "" characters in		list. The same considerations apply for the "," and "\" characters
	docpath-segments for zone-file implementations and the alpn-ids in an		in docpath-segments for zone-file implementations and the alpn-ids in
	"alpn" SvcParam (Section 7.1.1 of [RFC9460]).		an "alpn" SvcParam (Section 7.1.1 of [RFC9460]).
	The wire-format value for "docpath" consists of 0 or more sequences		The wire-format value for "docpath" consists of 0 or more sequences
	of octets prefixed by their respective length as a single octet. We		of octets prefixed by their respective length as a single octet. We
	call this single octet the length octet. The length octet and the		call this single octet the length octet. The length octet and the
	corresponding sequence form a length-value pair. These length-value		corresponding sequence form a length-value pair. These length-value
	pairs are concatenated to form the SvcParamValue. These pairs MUST		pairs are concatenated to form the SvcParamValue. These pairs MUST
	exactly fill the SvcParamValue; otherwise, the SvcParamValue is		exactly fill the SvcParamValue; otherwise, the SvcParamValue is
	malformed. Each such length-value pair represents one segment of the		malformed. Each such length-value pair represents one segment of the
	absolute path to the DoC resource. The root path "/" is represented		absolute path to the DoC resource. The root path "/" is represented
	by 0 length-value pairs, i.e., SvcParamValue length 0.		by 0 length-value pairs, i.e., SvcParamValue length 0.
	Note that this format uses the same encoding as the "alpn" SvcParam,		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		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-		adaption that a length of zero is allowed. As long as each docpath-
	segment is of length 0 and 24 octets, it is easily transferred into		segment has a length between 0 and 23 octets, inclusive, it is easily
	the path representation in CRIs [CRI] by masking each length octet		transferred into the path representation in CRIs [CRI] by masking
	with the CBOR text string major type 3 (0x60 as an octet; see		each length octet with the CBOR text string major type 3 (0x60 as an
	[RFC8949]). Furthermore, it is easily transferable into a sequence		octet; see [RFC8949]). Furthermore, it is easily transferable into a
	of CoAP Uri-Path options by mapping each length octet into the Option		sequence of CoAP Uri-Path options by mapping each length octet into
	Delta and Option Length of the corresponding CoAP Uri-Path option,		the Option Delta and Option Length of the corresponding CoAP Uri-Path
	provided the docpath-segments are all of a length between 0 and 12		option, provided the docpath-segments are all of a length between 0
	octets (see [RFC7252], Section 3.1). Likewise, it can be transferred		and 12 octets (see [RFC7252], Section 3.1). Likewise, it can be
	into a URI path-abempty form by replacing each length octet with the		transferred into a URI path-abempty form by replacing each length
	"/" character None of the abovementioned prevent longer docpath-		octet with the "/" character. None of the abovementioned prevent
	segments than the considered, they just make the translation harder,		longer docpath-segments than the considered ones; they just make the
	as they require to make space for the longer delimiters, in turn		translation harder as space is required for the longer delimiters,
	requiring to move octets.		which in turn require octets to be moved.
	To use the service binding from an SVCB RR or DNR Encrypted DNS		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		option, the DoC client MUST send a DoC request constructed from the
	SvcParams including "docpath". The construction algorithm for DoC		SvcParams including "docpath". The construction algorithm for DoC
	requests is as follows, going through the provided records in order		requests is as follows, with the provided records in order of their
	of their priority. For the purposes of this algorithm, the DoC		priority. For the purposes of this algorithm, the DoC client is
	client is assumed to be SVCB-optional (see Section 3 of [RFC9460]).		assumed to be SVCB-optional (see Section 3 of [RFC9460]).
	* If the "alpn" SvcParam value for the service is "coap", a CoAP		* If the "alpn" SvcParam value for the service is "coap", a CoAP
	request for CoAP over TLS MUST be constructed [RFC8323]. If it is		request for CoAP over TLS MUST be constructed [RFC8323]. If it is
	"co", a CoAP request for CoAP over DTLS MUST be constructed		"co", a CoAP request for CoAP over DTLS MUST be constructed
	[PRE-RFC9952]. Any other SvcParamKeys specifying a transport are		[PRE-RFC9952]. Any other SvcParamKeys specifying a transport are
	out of the scope of this document.		out of the scope of this document.
	* The destination address for the request SHOULD be taken from		* The destination address for the request SHOULD be taken from
	additional information about the target. This may include (1) A		additional information about the target. This may include (1) A
	or AAAA RRs associated with the target name and delivered with the		or AAAA RRs associated with the target name and delivered with the
	SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams		SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams
	from the SVCB RR (see [RFC9461]), or (3) from IPv4 or IPv6		from the SVCB RR (see [RFC9461]), or (3) IPv4 or IPv6 addresses
	addresses provided if DNR [RFC9463] is used. As a fallback, an		provided if DNR [RFC9463] is used. As a fallback, an address MAY
	address MAY be queried for the target name of the SVCB record from		be queried for the target name of the SVCB record from another DNS
	another DNS service.		service.
	* The destination port for the request MUST be taken from the "port"		* The destination port for the request MUST be taken from the "port"
	SvcParam value, if present. Otherwise, take the default port of		SvcParam value, if present. Otherwise, take the default port of
	the CoAP transport, e.g., with regards to this specification, the		the CoAP transport, e.g., with regards to this specification, the
	default is TCP port 5684 for "coap" or UDP port 5684 for "co".		default is TCP port 5684 for "coap" or UDP port 5684 for "co".
	This document introduces no limitations on the ports that can be		This document introduces no limitations on the ports that can be
	used. If a malicious SVCB record allows its originator to		used. If a malicious SVCB record allows its originator to
	influence message payloads, Section 12 of [RFC9460] recommends		influence message payloads, Section 12 of [RFC9460] recommends
	placing such restrictions in the SVCB mapping document. The		placing such restrictions in the SVCB mapping document. The
	records used in this document only influence the Uri-Path option.		records used in this document only influence the Uri-Path option.
	skipping to change at line 367 ¶		skipping to change at line 367 ¶
	A more generalized construction algorithm for any CoAP request can be		A more generalized construction algorithm for any CoAP request can be
	found in [TRANSPORT-IND].		found in [TRANSPORT-IND].
	3.2.1. Examples		3.2.1. Examples
	A typical SVCB resource record response for a DoC server at the root		A typical SVCB resource record response for a DoC server at the root
	path "/" of the server looks like the following (the "docpath"		path "/" of the server looks like the following (the "docpath"
	SvcParam is the last 4 bytes 00 0a 00 00 in the binary):		SvcParam is the last 4 bytes 00 0a 00 00 in the binary):
	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 )
	The root path is RECOMMENDED but not required. Here are two examples		The root path is RECOMMENDED but not required. Here are two examples
	where the "docpath" represents paths of varying depth. First, "/dns"		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		is provided in the following example (the last 8 bytes 00 0a 00 04 03
	64 6e 73):		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 )
	Second, see an example for the path "/n/s" (the last 8 bytes 00 0a 00		Second, see an example for the path "/n/s" (the last 8 bytes 00 0a 00
	04 01 6e 01 73):		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 )
	If the server also provides DNS over HTTPS, "dohpath" and "docpath"		If the server also provides DNS over HTTPS, "dohpath" and "docpath"
	MAY coexist:		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 )
	4. Basic Message Exchange		4. Basic Message Exchange
	4.1. The "application/dns-message" Content-Format		4.1. The "application/dns-message" Content-Format
	This document defines a CoAP Content-Format ID for the Internet media		This document defines a CoAP Content-Format ID for the Internet media
	type "application/dns-message" to be the mnemonic 553, based on the		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		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-		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		wire format [STD13]. Both DoC client and DoC server MUST be able to
	skipping to change at line 479 ¶		skipping to change at line 479 ¶
	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		resolve "example.org. IN AAAA" based on the URI
	"coaps://[2001:db8::1]/". The CoAP body is encoded in the		"coaps://[2001:db8::1]/". The CoAP body is encoded in the
	"application/dns-message" Content-Format.		"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
	4.3. DNS Responses in CoAP Responses		4.3. DNS Responses in CoAP Responses
	Each DNS query-response pair is mapped to a CoAP request-response		Each DNS query-response pair is mapped to a CoAP request-response
	operation. DNS responses are provided in the body of the CoAP		operation. DNS responses are provided in the body of the CoAP
	response, i.e., it is also possible to transfer them using block-wise		response, i.e., it is also possible to transfer them using block-wise
	transfer [RFC7959]. A DoC server MUST be able to produce responses		transfer [RFC7959]. A DoC server MUST be able to produce responses
	in the "application/dns-message" Content-Format (for details, see		in the "application/dns-message" Content-Format (for details, see
	Section 4.1) when requested. The use of the Accept option in the		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		request is OPTIONAL. However, all DoC clients MUST be able to parse
	an "application/dns-message" response (see also Section 4.1). Any		an "application/dns-message" response (see also Section 4.1). Any
	response Content-Format other than "application/dns-message" MUST be		response Content-Format other than "application/dns-message" MUST be
	indicated with the Content-Format option by the DoC server.		indicated with the Content-Format option by the DoC server.
	4.3.1. Response Codes and Handling DNS and CoAP Errors		4.3.1. Response Codes and Handling DNS and CoAP Errors
	A DNS response indicates either success or failure in the RCODE of		A DNS response indicates either success or failure in the RCODE of
	the DNS header (see [STD13]). It is RECOMMENDED that CoAP responses		the DNS header (see [STD13]). It is RECOMMENDED that CoAP responses
	that carry a parsable DNS response use a 2.05 (Content) response		that carry a parsable DNS response use a 2.05 (Content) response
	code.		code.
	skipping to change at line 581 ¶		skipping to change at line 581 ¶
	"example.org. IN AAAA record", with recursion turned on. Successful		"example.org. IN AAAA record", with recursion turned on. Successful
	responses carry one answer record including the address		responses carry one answer record including the address
	2001:db8:1:0:1:2:3:4 and TTL 79689.		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
	When a DNS error -- NxDomain (RCODE = 3) for "does.not.exist" in this		When a DNS error - NxDomain (RCODE = 3) for "does.not.exist" in this
	case -- is noted in the DNS response, the CoAP response still		case - is noted in the DNS response, the CoAP response still
	indicates success.		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
	As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if		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		it does not support an OPCODE - in this case, it errors on a DNS
	"example.org" in this case.		Update (OPCODE = 5) for "example.org".
	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
	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-		an appropriate CoAP error, for instance, 4.15 (Unsupported Content-
	Format) if the Content-Format option in the request was not set to		Format) if the Content-Format option in the request was not set to
	"application/dns-message" and the Content-Format is not otherwise		"application/dns-message" and the Content-Format is not otherwise
	supported by the server.		supported by the server.
	4.15 Unsupported Content-Format		4.15 Unsupported Content-Format
	[no payload]		[no payload]
	skipping to change at line 640 ¶		skipping to change at line 640 ¶
	However, it results in additional overhead, which conflicts with		However, it results in additional overhead, which conflicts with
	constrained resources. This is the reason why it is RECOMMENDED to		constrained resources. This is the reason why it is RECOMMENDED to
	use CoAP Observe [RFC7641] instead of DNS Push in the DoC domain.		use CoAP Observe [RFC7641] instead of DNS Push in the DoC domain.
	This is particularly useful if a short-lived record is requested		This is particularly useful if a short-lived record is requested
	frequently. The DoC server SHOULD provide Observe capabilities on		frequently. The DoC server SHOULD provide Observe capabilities on
	its DoC resource and do as follows.		its DoC resource and do as follows.
	If a DoC client wants to observe a resource record, a DoC server can		If a DoC client wants to observe a resource record, a DoC server can
	respond with a notification and add the client to its list of		respond with a notification and add the client to its list of
	observers for that resource in accordance with [RFC7641]. The DoC		observers for that resource in accordance with [RFC7641]. The DoC
	server MAY subscribe to DNS push notifications for that record. This		server MAY subscribe to DNS Push Notifications for that record. This
	involves sending a DNS Subscribe message (see Section 6.2 of		involves sending a DNS Subscribe message (see Section 6.2 of
	[RFC8765]), instead of a classic DNS query to fetch the information		[RFC8765]), instead of a classic DNS query to fetch the information
	on behalf of the DoC client.		on behalf of the DoC client.
	After the list of observers for a particular DNS query has become		After the list of observers for a particular DNS query has become
	empty (by explicit or implicit cancellation of the observation as per		empty (by explicit or implicit cancellation of the observation as per
	Section 3.6 of [RFC7641]), and no other reason to subscribe to that		Section 3.6 of [RFC7641]), and no other reason to subscribe to that
	request is present, the DoC server SHOULD cancel the corresponding		request is present, the DoC server SHOULD cancel the corresponding
	subscription. This can involve sending a DNS Unsubscribe message or		subscription. This can involve sending a DNS Unsubscribe message or
	closing the session (see Section 6.4 of [RFC8765]). As there is no		closing the session (see Section 6.4 of [RFC8765]). As there is no
	CoAP observer anymore from the perspective of the DoC server, a		CoAP observer anymore from the perspective of the DoC server, a
	failure to do so cannot be communicated back to any DoC observer. As		failure to unsubscribe or close the session cannot be communicated
	such, error handling (if any) needs to be resolved between the DoC		back to any DoC observer. As such, error handling (if any) needs to
	server and the upstream DNS infrastructure.		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		infrastructure for an observed resource record, the DoC server sends
	an appropriate Observe notification response to the DoC client.		an appropriate Observe notification response to the DoC client.
	A server that responds with notifications (i.e., sends the Observe		A server that responds with notifications (i.e., sends the Observe
	option) needs to have the means of obtaining current resource		option) needs to have the means of obtaining current resource
	records. This may happen through DNS Push or also by upstream		records. This may happen through DNS Push or also by upstream
	polling or implicit circumstances (e.g., if the DoC server is the		polling or implicit circumstances (e.g., if the DoC server is the
	authoritative name server for the record and wants to notify about		authoritative name server for the record and wants to notify about
	changes).		changes).
	5.2. OSCORE		5.2. OSCORE
	It is RECOMMENDED to carry DNS messages protected using OSCORE		It is RECOMMENDED to carry DNS messages protected using OSCORE
	[RFC8613] between the DoC client and the DoC server. The		[RFC8613] between the DoC client and the DoC server. The
	establishment and maintenance of the OSCORE security context is out		establishment and maintenance of the OSCORE security context is out
	of the scope of this document.		of the scope of this document.
	[CACHABLE-OSCORE] describes a method to allow cache retrieval of		[CACHEABLE-OSCORE] describes a method to allow cache retrieval of
	OSCORE responses and discusses the corresponding implications on		OSCORE responses and discusses the corresponding implications on
	message sizes and security properties.		message sizes and security properties.
	5.3. Mapping DoC to DoH		5.3. Mapping DoC to DoH
	This document provides no specification on how to map between DoC and		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		DoH, e.g., at a CoAP-to-HTTP proxy. Such a direct mapping is NOT
	RECOMMENDED: Rewriting the FETCH method (Section 4.2) and TTL		RECOMMENDED: Rewriting the FETCH method (Section 4.2) and TTL
	(Section 4.3.2) as specified in this document would be non-trivial.		(Section 4.3.2) as specified in this document would be non-trivial.
	It is RECOMMENDED to use a DNS forwarder to map between DoC and DoH,		It is RECOMMENDED to use a DNS forwarder to map between DoC and DoH,
	skipping to change at line 708 ¶		skipping to change at line 709 ¶
	message is unprotected, it MUST use a random token with a length of		message is unprotected, it MUST use a random token with a length of
	at least 2 bytes to mitigate this kind of poisoning attack.		at least 2 bytes to mitigate this kind of poisoning attack.
	7. Security Considerations		7. Security Considerations
	General CoAP security considerations ([RFC7252], Section 11) apply to		General CoAP security considerations ([RFC7252], Section 11) apply to
	DoC. DoC also inherits the security considerations of the protocols		DoC. DoC also inherits the security considerations of the protocols
	used for secure communication, e.g., OSCORE ([RFC8613], Section 12)		used for secure communication, e.g., OSCORE ([RFC8613], Section 12)
	as well as DTLS 1.2 or newer ([RFC6347], Section 5 and [RFC9147],		as well as DTLS 1.2 or newer ([RFC6347], Section 5 and [RFC9147],
	Section 11). Additionally, DoC uses request patterns that require		Section 11). Additionally, DoC uses request patterns that require
	the maintenance of long-lived security contexts. Section 2.6 of		the maintenance of long-lived security contexts. Section 2.7 of
	[CoAP-CORR-CLAR] provides insights on what can be done when those are		[CoAP-CORR-CLAR] provides insights on what can be done when those are
	resumed from a new endpoint.		resumed from a new endpoint.
	Though DTLS v1.2 [RFC6347] was obsoleted by DTLS v1.3 [RFC9147],		Though DTLS v1.2 [RFC6347] was obsoleted by DTLS v1.3 [RFC9147],
	there are many CoAP implementations that still use v1.2 at the time		there are many CoAP implementations that still use v1.2 at the time
	of writing. As such, this document also accounts for the usage of		of writing. As such, this document also accounts for the usage of
	DTLS v1.2 even though newer versions are RECOMMENDED when using DTLS		DTLS v1.2 even though newer versions are RECOMMENDED when using DTLS
	to secure CoAP.		to secure CoAP.
	When using unprotected CoAP (see Section 6), setting the ID of a DNS		When using unprotected CoAP (see Section 6), setting the ID of a DNS
	skipping to change at line 988 ¶		skipping to change at line 989 ¶
	<https://www.rfc-editor.org/info/rfc9499>.		<https://www.rfc-editor.org/info/rfc9499>.
	[BCP237] Best Current Practice 237,		[BCP237] Best Current Practice 237,
	<https://www.rfc-editor.org/info/bcp237>.		<https://www.rfc-editor.org/info/bcp237>.
	At the time of writing, this BCP comprises the following:		At the time of writing, this BCP comprises the following:
	Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,		Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
	RFC 9364, DOI 10.17487/RFC9364, February 2023,		RFC 9364, DOI 10.17487/RFC9364, February 2023,
	<https://www.rfc-editor.org/info/rfc9364>.		<https://www.rfc-editor.org/info/rfc9364>.
	[CACHABLE-OSCORE]		[CACHEABLE-OSCORE]
	Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in		Amsüss, C. and M. Tiloca, "End-to-End Protected and
	Progress, Internet-Draft, draft-amsuess-core-cachable-		Cacheable Responses for the Constrained Application
	oscore-11, 6 July 2025,		Protocol (CoAP) using Group Object Security for
	<https://datatracker.ietf.org/doc/html/draft-amsuess-core-		Constrained RESTful Environments (Group OSCORE)", Work in
	cachable-oscore-11>.		Progress, Internet-Draft, draft-ietf-core-cacheable-
			oscore-01, 2 March 2026,
			<https://datatracker.ietf.org/doc/html/draft-ietf-core-
			cacheable-oscore-01>.
	[CoAP-CORR-CLAR]		[CoAP-CORR-CLAR]
	Bormann, C., "Constrained Application Protocol (CoAP):		Bormann, C., "Constrained Application Protocol (CoAP):
	Corrections and Clarifications", Work in Progress,		Corrections and Clarifications", Work in Progress,
	Internet-Draft, draft-ietf-core-corr-clar-03, 22 December		Internet-Draft, draft-ietf-core-corr-clar-03, 22 December
	2025, <https://datatracker.ietf.org/doc/html/draft-ietf-		2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
	core-corr-clar-03>.		core-corr-clar-03>.
	[CRI] Bormann, C. and H. Birkholz, "Constrained Resource		[CRI] Bormann, C. and H. Birkholz, "Constrained Resource
	Identifiers", Work in Progress, Internet-Draft, draft-		Identifiers", Work in Progress, Internet-Draft, draft-
	ietf-core-href-30, 21 November 2025,		ietf-core-href-30, 21 November 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-core-		<https://datatracker.ietf.org/doc/html/draft-ietf-core-
	href-30>.		href-30>.
	[DoC-paper]		[DoC-paper]
	Lenders, M., Amsüss, C., Gündogan, C., Nawrocki, M.,		Lenders, M. S., Amsüss, C., Gündogan, C., Nawrocki, M.,
	Schmidt, T., and M. Wählisch, "Securing Name Resolution in		Schmidt, T., and M. Wählisch, "Securing Name Resolution in
	the IoT: DNS over CoAP", Proceedings of the ACM on		the IoT: DNS over CoAP", Proceedings of the ACM on
	Networking, vol. 1, no. CoNEXT2, pp. 1-25,		Networking, vol. 1, no. CoNEXT2, pp. 1-25,
	DOI 10.1145/3609423, September 2023,		DOI 10.1145/3609423, September 2023,
	<https://doi.org/10.1145/3609423>.		<https://doi.org/10.1145/3609423>.
	[REST] Fielding, R., "Architectural Styles and the Design of		[REST] Fielding, R., "Architectural Styles and the Design of
	Network-based Software Architectures", Ph.D. Dissertation,		Network-based Software Architectures", Ph.D. Dissertation,
	University of California, Irvine, 2000,		University of California, Irvine, 2000,
	<https://www.ics.uci.edu/~fielding/pubs/dissertation/		<https://www.ics.uci.edu/~fielding/pubs/dissertation/
	skipping to change at line 1107 ¶		skipping to change at line 1111 ¶
	Acknowledgments		Acknowledgments
	The authors of this document want to thank Mike Bishop, Carsten		The authors of this document want to thank Mike Bishop, Carsten
	Bormann, Mohamed Boucadair, Deb Cooley, Vladimír Čunát, Roman		Bormann, Mohamed Boucadair, Deb Cooley, Vladimír Čunát, Roman
	Danyliw, Elwyn B. Davies, Esko Dijk, Gorry Fairhurst, Thomas Fossati,		Danyliw, Elwyn B. Davies, Esko Dijk, Gorry Fairhurst, Thomas Fossati,
	Mikolai Gütschow, Todd Herr, Tommy Pauly, Jan Romann, Ben Schwartz,		Mikolai Gütschow, Todd Herr, Tommy Pauly, Jan Romann, Ben Schwartz,
	Orie Steele, Marco Tiloca, Éric Vyncke, Tim Wicinski, and Paul		Orie Steele, Marco Tiloca, Éric Vyncke, Tim Wicinski, and Paul
	Wouters for their feedback and comments.		Wouters for their feedback and comments.
			This work was supported in parts by the German Federal Ministry of
			Research, Technology and Space (BMFTR) under the grant numbers
			16KIS1386K (TU Dresden) and 16KIS1387 (HAW Hamburg) within the
			research project PIVOT and under the grant numbers 16KIS1694K (TU
			Dresden) and 16KIS1695 (HAW Hamburg) within the research project
			C-ray4edge.
	Authors' Addresses		Authors' Addresses
	Martine Sophie Lenders		Martine Sophie Lenders
	TUD Dresden University of Technology		TUD Dresden University of Technology
	Helmholtzstr. 10		Helmholtzstr. 10
	D-01069 Dresden		D-01069 Dresden
	Germany		Germany
	Email: martine.lenders@tu-dresden.de		Email: martine.lenders@tu-dresden.de
	Christian Amsüss		Christian Amsüss
End of changes. 35 change blocks.
	103 lines changed or deleted		114 lines changed or added
This html diff was produced by rfcdiff 1.48.