DNS over CoAP (DoC)
draft-ietf-core-dns-over-coap-20

One more item I noticed while preparing the ballot: the abstract and introduction state the use of DTLS and OSCORE for message protection, but TLS is also supported according to the remaining sections. Please either explicitly mention TLS or adjust to "(D)TLS" where appropriate.

Hi Martine, Christian, Cenk, Thomas, and Matthias, 

Thank you for the effort put into this specification.

Also, thanks to Tim Wicinski for the DNSDIR reviews and for the authors for taking care of his comments.

Although there are a bunch of DNS transport out there (Do53, DoT, DoQ, DoH, etc.), the motivations for DoC are solid. Better, the proposed design is well-thought. I support this effort, hence my "Yes" ballot.

Please find below some comments; major comments are tagged with (*):

# Lack of operation considerations (*)

Other than discovery, the document does not discuss operational considerations that are worth to take into account to ease the deployability of DoC. At least, co-existence considerations (when several transport flavors are supported) should be covered (e.g., preference order). The following additional points may be considered:

## Redirection (*)

Likewise, do we allow (and thus need to support) server redirection in case of 5.03? We should be explicit about the expected behavior. An example of deployment case where redirection support may be useful is: bootstrapping with a centralized DoC server and then redirect the DoC client to a local DoC server. I’m not pushing for any direction here, but simply providing an example of aspects to cover.

## Confirmable and Non-Confirmable (*)

Should the spec provide more guidance about which mode should be used by default? I guess, the default mode is Confirmable. Right?

## Control of CoAP Proxy Hops (*)

The spec mentions CoAP proxies, but I wonder whether it needs to mention the use of Hop-Limit Option to control how queries are propagated or help detect infinite loops due to incorrect proxy configuration.

## Troubleshooting (*)

Do we need extra codes to demux DNS-related errors vs. conventional CoAP? For example, CoAP leg may be OK but the upstream DNS query may not be sent out because of a DNS failure. How to report that back to the DoC client?

# SVCB is normative  (*)

Text such as (and similar)

   This document specifies "docpath" as a single-valued SvcParamKey that
   is mandatory for DoC SVCB records.  

or

   Paths with longer segments cannot be advertised
   with the "docpath" SvcParam and are thus NOT RECOMMENDED for the path
   to the DoC resource.

Suggests that understanding the concept of SvcParam is required. I suggest to cite SVCB as normative.

# Recursion termination in the CoAP realm

Figure 1 may be interpreted as if “conventional” DNS message will always be triggered by a query from a DoC client. Should we mention that DoC server can terminate the query if it is authoritative for the queried resource?

# Back-to-Back DoC Server and Do53/DoT/DoH

There is no mapping frozen in the spec between various DNS transport. It would be cleaner from an architectural standpoint to indicate the B2B entity in Figure 1.

# Trusted source

CURRENT:
  Automatic configuration
   SHOULD only be done from a trusted source.
 
Why isn’t this a MUST?

# On OSCORE

CURRENT:
   Because the ALPN extension is only
   defined for (D)TLS, these mechanisms cannot be used for DoC servers
   which use only OSCORE [RFC8613] and Ephemeral Diffie-Hellman Over
   COSE (EDHOC) [RFC9528] (with COSE abbreviating "Concise Binary Object
   Notation (CBOR) Object Signing and Encryption" [RFC9052]) for
   security.  

Please note that DNR says the following:

      The "alpn" SvcParam may not be required in contexts such as a
      variant of DNS over the Constrained Application Protocol (CoAP)
      where messages are encrypted using Object Security for Constrained
      RESTful Environments (OSCORE) [RFC8613]. 

# Mysterious destination IP address (*)

CURRENT:
   *  The destination address for the request SHOULD be taken from
      additional information about the target, e.g., from an AAAA resource record
      associated with the target name or from an "ipv6hint" SvcParam

How we got that resolution as at this stage we don’t have a DNS server to communicate with? Maybe I’m missing something.

# Redundant requirement?

CURRENT:
   A DoC server MUST be able to parse requests of
   Content-Format "application/dns-message".

How is this different from:

  “Both DoC client and DoC server MUST be able to parse contents in the "application/dns-message"
  Content-Format"?

# I-D.ietf-iotops-7228bis note

It is unlikely that I-D.ietf-iotops-7228bis will make it before DoC. I suggest you simply delete that RFC Editor note.

Cheers,
Med

Thanks for addressing my concerns. I have updated my ballot to Yes

# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05
CC @evyncke

Thank you for the work put into this document. Like others, I was puzzled at first sight about a n+1 mechanism to transport DNS traffic, but after reading the motivation in section 1, it does make sense even if actual data (packet size, transaction, ...) would be helpful as DNS payload is already compressed.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Marco Tiloca for the shepherd's write-up including the WG consensus and the justification of the intended status.

Other thanks to Vladimír Čunát , the DNS directorate reviewer (at my request), please consider this dns-dir review:
https://datatracker.ietf.org/doc/review-ietf-core-dns-over-coap-17-dnsdir-telechat-cunat-2025-07-31/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Abstract

Please mention that only OPCODE=0 is supported, i.e., not 'generic DNS messages' but only "DNS queries".

### Section 1

Rather than using RFC 1035, you may want to use STD 13.

Please mention that only OPCODE=0 is supported, i.e., not 'generic DNS messages' but only "DNS queries".

s/link layer frame sizes/link-layer frame sizes/ ?

Thanks for providing SVG graphics, the HTML rendering is so much nicer :)

### Section 3.2

Should there be a space in `255OCTET`?

### Section 4.1

Is there any way for provide an extension to other RR codes ? `For the purposes of this document, only OPCODE 0 (Query) is supported for DNS messages. Future work might provide specifications and considerations for other values of OPCODE.` seems rather vague about extension points. The UPDATE op-code could be very interesting.

### Section 4.2.3

As there is only one example, please use singular in the section title.

### Section 8

s/That information can also imply trust in the DNSSEC validation by that server./That information can also imply trust in the DNSSEC validation by that *DoC* server./

More generally, I was expecting more text about DNSSEC earlier in the text, e.g, by stating that a DoC server MAY (or SHOULD or MUST) be the DNSSEC validator.

Rather then referring to RFC 9364, you may want to refer to BCP 237.