Martine, Thanks for the proposed updated text regarding CNAMEs. I agree that it is an improvement, but I still think it would be better to omit entirely. By writing that implementations SHOULD follow RFC 1034, you imply that they are permitted not to, which seems objectionable. I think it would be much clearer to simply say that use of DoC does not alter the DNS message contents.
I feel similarly about the Additional section. If you think that it would be useful to deviate from ordinary practices regarding the Additional section, I think this should be in a separate draft on compact DNS responses, not coupled to DoC. For example, such compactification might be even more relevant to UDP Do53 than to DoC. --Ben On Mon, Sep 19, 2022 at 7:30 AM Martine Sophie Lenders < m.lend...@fu-berlin.de> wrote: > Hi, > > Sorry for the late reply, I was away from any keyboard for the past two > weeks. > > I think there might be a misunderstanding regarding the CNAME behavior, > due to some poor wording in our draft: The CNAMEs should, of course, only > be resolved in such a way, if the queried record was an A or AAAA record. > This does not, to my understanding, contradict the behavior described for > CNAMEs in RFC 1034. We propose a different wording for the first sentence > in 5.1 to prevent such misunderstandings in the future: > > In the case of CNAME records in a DNS response to an A or AAAA record > query, a DoC server SHOULD follow common DNS resolver behavior [RFC1034 > <https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-00.html#RFC1034> > ] by resolving a CNAME until the originally requested resource record > type is reached. > > Regarding the population of the additional section, we also follow > recommendations in RFC 1034, to only include records useful to the client. > We deem this particularly noteworthy when it comes to DNS, as from our > analysis of DNS traffic, responses can become quite large due to an > abundance of records in the Additional section. With the message size > constraints in LLNs, it might thus be necessary to prune the DNS message > for records actually useful to the querying DoC client. > > Lastly, mind, that, at least in our model for DoC, a DoC client does not > further distribute the information it gathered via DoC. > > Regards > Martine > > Am 06.09.22 um 17:06 schrieb Ben Schwartz: > > Some further notes on this draft. > > Section 5.1 says that a DoC server "SHOULD" follow CNAMEs. This is a > misunderstanding of the nature of DNS transports. DoC is a DNS transport, > like DoT and DoH. The choice of transport is independent of the DNS > server's answering behavior, which must not be modified by the transport. > Indeed, DPRIVE is now chartered to enable the use of alternate transports > for recursive-to-authoritative queries for which CNAME following has > entirely different rules. This is possible precisely because the choice of > transport does not alter the logical DNS contents. > > Section 5.1 also proposes that the population of the Additional section > might follow different logic when using DoC. > > Modifying the logical DNS behavior would create a wide range of exciting > and unpredictable compatibility issues when trying to use a new transport. > I urge the authors to delete Section 5.1, which would resolve this > problem. The draft could instead note that the DNS queries and responses > are not modified when using DoC, except under private arrangement between > the client and server. > > On Fri, Sep 2, 2022 at 12:20 PM Jaime Jiménez <ja...@iki.fi> wrote: > >> Dear CoRE WG, >> >> Thanks to the authors and the reviewers that provided comments on the >> list for this draft. Given the in-room support and the list discussion >> during the WGA the chairs believe that there is sufficient support for the >> adoption of this document in CoRE. >> >> The authors are advised to resubmit the draft-core-dns-over-coap and to >> set up a document repo under the CoRE Github organization at >> https://github.com/core-wg >> >> BR, >> >> Jaime Jiménez on behalf of the CoRE chairs. >> On 15.8.2022 11.26, Jaime Jiménez wrote: >> >> Dear CoRE WG, >> >> We would like to start the call for adoption on draft-lenders-dns-over-coap. >> The draft defines a protocol for sending DNS messages over secure CoAP (DTLS >> and/or OSCORE). The draft was discussed during IETF114 and on IETF113 and >> was well-received by the group. >> https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/ >> >> During the last IETF meeting there were no objections for adoption so we >> confirm this now on the mailing list. Please let us know if you support >> adopting this draft. As many people will still be on vacation, we the WGA >> call will last a couple of weeks, ending the *1st of September*. >> >> Note that DNSOP and DPRIVE are in the loop as the draft is relevant for >> their working groups too. >> >> BR, >> >> -- >> Jaime Jiménez >> >> >> _______________________________________________ >> core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core >> >> -- >> Jaime Jiménez >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
