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 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 291 ¶		skipping to change at line 291 ¶
	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
	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 652 ¶		skipping to change at line 652 ¶
	[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 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-
End of changes. 27 change blocks.
	90 lines changed or deleted		94 lines changed or added
This html diff was produced by rfcdiff 1.48.