Summary

  • RFC 9953 lets a DoC client set a DNS header ID to zero so equivalent body-carried DNS queries can share a CoAP Cache-Key.
  • The cacheable representation remains bounded by a time calculation and by separate evidence for DNS status, responder role, validation, local policy and actual use.

Imagine a small controller waking after a long sleep. It asks a resolver for one name, and an en-route CoAP cache has a representation that matches the request. The response arrives cheaply. That is a useful engineering outcome. It is not yet a verdict that the response is authoritative, DNSSEC validated, still permitted by local policy, or the basis on which an actuator safely changed state.

RFC 9953, published in March 2026, defines DNS over CoAP, or DoC, for ordinary DNS queries using OPCODE 0. One DNS query-response pair becomes one CoAP request-response operation. The DNS wire message is carried in the body of CoAP FETCH, with application/dns-message registered as Content-Format 553. That design is aimed at constrained environments where a body-carrying request, block-wise transfer and CoAP caching can be useful. It does not erase the older distinctions inside DNS.

The compact detail that matters most is the DNS header ID. A DoC client SHOULD set it to zero so that repeated requests for the same DNS data do not create different CoAP Cache-Keys merely because the traditional DNS transaction identifier changed. A cache, including an en-route proxy, can then reuse its representation. The DoC server MUST copy the query ID into the response. Zero is not a security assertion and it is not a resolver identity. It is a controlled normalization of one cache-key input.

That normalization is deliberately paired with a clock. RFC 9953 says a DoC server MUST ensure that the Max-Age of a CoAP response plus every DNS TTL carried in it is no greater than the corresponding TTL it received upstream. The rule includes CoAP's default 60-second Max-Age when the option is absent. A DoC client, on receiving the response, MUST add the response's Max-Age to each DNS TTL and use the calculated values. The two values are not duplicate decoration. Together they preserve the lifetime budget across a transport cache and the DNS representation inside it.

The recommended server algorithm makes the purpose clearer. Set Max-Age to the smallest DNS TTL in the response and subtract that same value from all DNS TTLs in the body. An intermediate cache can then retain the representation without accidentally extending an expired DNS record, while a content-based CoAP ETag need not change merely because an upstream cache refreshed its remaining TTL. A short-lived error may need a smaller Max-Age, even zero. This is a mechanism for preventing an unjustified extension of time; it is not a promise that every error is equivalent or every answer is safe to act on.

The response code supplies a second discipline. A parsable DNS response is recommended to arrive in CoAP 2.05 Content even if DNS itself says NXDOMAIN or another RCODE failure. Non-successful CoAP codes are for a CoAP-layer error or a request that fails the DoC protocol requirements, such as an unsupported content format. Reading the outer 2.05 as “the DNS answer succeeded” would discard the DNS outcome. Reading a DNS RCODE as “the transport failed” would discard the transport outcome. Operations need both coordinates.

The server role is also not settled by the cache. RFC 9953 allows a DoC server to be an authoritative server, a stub or recursive resolver that uses other upstream DNS transports, and it says the server MAY be a DNSSEC validator for constrained clients. The word “may” matters. A protected (D)TLS or OSCORE exchange can establish properties of the channel or object protection; it does not silently identify the upstream source, prove universal DNSSEC validation, decide a client's local policy, or record what a later application did.

Daniel Kade's use of Heng Lu's running-code lens is editorial, not a new protocol rule: cacheability, source, validation, time, authorization and observed effect are different facts. RFC 9953 gives them a clean place to be recorded. It is strongest when an operator refuses to let one efficient cache hit stand in for all of them.

Sources