DNS over CoAP (DoC)
Extracted elements (30)
CoAP Observe is RECOMMENDED over DNS Push Notifications for the DoC domain because DNS Push introduces additional overhead incompatible with constrained resources, whereas CoAP Observe reuses existing CoAP machinery and is particularly beneficial for frequently requested short-lived records.
Direct protocol mapping between DoC and DoH at a CoAP-to-HTTP proxy is NOT RECOMMENDED because rewriting the FETCH method semantics and the TTL/Max-Age relationship would be non-trivial. A DNS forwarder should be used instead, as with any other pair of DNS transports.
OSCORE is offered as an alternative to DTLS/TLS to avoid the resource overhead of session-layer security on constrained IoT devices. OSCORE provides object-level security directly over CoAP without requiring a separate security handshake at the transport layer.
The CoAP FETCH method was chosen over GET and POST: it places the DNS query in the request body (avoiding base64 encoding required for GET), while retaining the same caching semantics as GET responses. This also enables block-wise transfer of large DNS queries.
The TTL/Max-Age algorithm (set Max-Age = min TTL, subtract min TTL from all TTLs) prevents cache poisoning from stale records in intermediate CoAP caches and keeps the ETag stable even as upstream caches update TTLs, enabling efficient CoAP cache validation.
DoC servers that use only OSCORE and EDHOC for security cannot be discovered using SVCB RR or DNR mechanisms, since those require an ALPN ID ("coap" for TLS, "co" for DTLS). Specifying an alternate discovery mechanism for OSCORE-only servers is out of scope.
Transport-specific DNS extensions such as edns-tcp-keepalive (RFC 7828) are not applicable to DoC, as they are specific to the choice of DNS transport and do not carry over to the CoAP transport layer.
When a DoC server also provides DNS over HTTPS, the "dohpath" and "docpath" SvcParams MAY coexist in the same SVCB record, and a client may select either service based on its capabilities.
A DoC client MUST include the DNS query in the body of the CoAP FETCH request, and the Content-Format option MUST indicate the content type ("application/dns-message", ID 553).
A DoC server MUST be able to produce responses in the "application/dns-message" Content-Format, and all DoC clients MUST be able to parse such responses. Any other response Content-Format MUST be indicated via the Content-Format option.
Automatic configuration of the DoC server (e.g., via DHCP, Router Advertisement, or resource directory) MUST only be performed from a trusted source.
CoAP responses with non-successful response codes MUST NOT contain a DNS response body; they MUST only be used for CoAP-layer errors or protocol violations. DNS operational errors (e.g., upstream timeouts) MUST be reported using the appropriate DNS RCODE inside a 2.xx CoAP response.
It is RECOMMENDED to carry DNS messages protected using OSCORE (RFC 8613) between DoC client and server. The use of DoC without confidentiality and integrity protection is NOT RECOMMENDED.
The DoC client SHOULD set the DNS header ID field to 0 so that CoAP caches (e.g., proxies) can match repeated queries for the same data. A DoC server MUST copy the ID from the DNS query into its response.
The DoC server MUST ensure that the sum of the CoAP Max-Age value and any DNS TTL in the response is less than or equal to the corresponding TTL received from the upstream DNS server. The DoC client MUST add the Max-Age value of the carrying CoAP response to all TTLs in the DNS response upon reception.
The request URI hostname MUST be the Authentication Domain Name (ADN) when obtained via DNR, or the SVCB target name when obtained via a _dns query. For each element in the "docpath" SvcParam, a Uri-Path option MUST be added to the request.
When constructing a DoC request from an SVCB record: if the "alpn" SvcParam is "coap", a CoAP-over-TLS request MUST be constructed; if it is "co", a CoAP-over-DTLS request MUST be constructed. The destination port MUST come from the "port" SvcParam if present, otherwise defaulting to TCP/UDP port 5684.
When using unprotected CoAP (no (D)TLS or OSCORE), a DoC message MUST use a random CoAP token with a length of at least 2 bytes to mitigate off-path cache poisoning attacks caused by setting the DNS ID to 0.
CoAP Observe (RFC 7641) is used for DNS Push-like subscriptions in DoC. The DoC server maintains a list of observers per DNS query; when the list empties, the server SHOULD cancel any corresponding upstream DNS Push subscription.
DoC uses the CoAP FETCH method (RFC 8132) to carry DNS queries. Each DNS query-response pair is mapped to a single CoAP request-response exchange. Only OPCODE 0 (Query) is specified.
The "docpath" SvcParamKey identifies the absolute path to the DoC resource in SVCB records. Each path segment is 1–255 octets; paths with segments exceeding 255 octets cannot be advertised and are NOT RECOMMENDED.
The media type "application/dns-message" is assigned CoAP Content-Format ID 553, based on the DNS port number. It carries a single DNS message in the DNS on-the-wire binary format as defined in STD13.
The resource type "core.dns" is defined for CoRE link-format discovery (RFC 6690) to identify a DoC resource. It allows clients to discover a generic DNS resolver via link mechanisms.
IANA added "core.dns" (description: "DNS over CoAP resource") to the "Resource Type (rt=) Link Target Attribute Values" registry in the CoRE Parameters group.
IANA added SvcParamKey number 10, name "docpath", meaning "DNS over CoAP resource path", to the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registry, with IETF as change controller.
IANA assigned CoAP Content-Format ID 553 for "application/dns-message" in the "CoAP Content-Formats" registry (CoRE Parameters group), referencing RFC 8484 and RFC 9953 Section 4.1.
A DoC client may delegate DNSSEC validation to its DoC server due to code size or response size constraints. The trust mechanism for this delegation (e.g., a specific credential recognizing an eligible DoC server) is out of scope for this document.
A DoC client must be aware that the DoC server may communicate unprotected (e.g., DNS over UDP) with upstream DNS infrastructure. DoC only guarantees confidentiality and integrity between parties sharing a security context; DNSSEC (BCP237) can provide record integrity upstream.
Setting the DNS message ID to 0 (as recommended for caching) when using unprotected CoAP exposes the DoC client's DNS cache to cache poisoning via response spoofing. This is mitigated by requiring a random CoAP token of at least 2 bytes in unprotected mode; (D)TLS and OSCORE make ID=0 safe.
The "docpath" SvcParamValue wire format consists of zero or more length-value pairs, each prefixed by a single-octet length field, concatenated to fill the SvcParamValue exactly. The root path "/" is encoded as zero length-value pairs (SvcParamValue length 0). This encoding matches that of the "alpn" SvcParam.