Preparing a separate document on compact DNS seems like a fine start to me.
On Wed, Sep 21, 2022 at 4:32 AM Martine Sophie Lenders < m.lend...@fu-berlin.de> wrote: > Hi Ben, Hi Carsten, > > thanks for your suggestions, Ben! It seems a good idea to clarify options > for compactification of DNS messages in a separate document, since the > compactification is indeed not bound to CoAP. We will prepare such a draft > until the cut-off for IETF 115, so we can discuss whether we keep or remove > Section 5.1 at the IETF meeting in London. Would that work for you? > > I tend to agree with Carsten. At least with the current wording (or the > proposed), the restatements may lead to confusion, but some guidelines for > the constrained use case should IMHO be part of the document, even if only > in reference to the new document proposed. > > Best > Martine > > Am 20.09.22 um 18:17 schrieb Carsten Bormann: > > I think we are falling into the restatement antipattern. > > This antipattern happens when documents restate mandates from their > references, invariably creating confusion if this is just a restatement or > actually new normative text that replaces or updates text from the > dependency. Don’t do that. > > Examples can be put into their own section and clearly marked as such. > > Grüße, Carsten > > Sent from mobile, sorry for terse > > On 20. Sep 2022, at 17:12, Ben Schwartz > <bemasc=40google....@dmarc.ietf.org> <bemasc=40google....@dmarc.ietf.org> > wrote: > > > 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 >> >> >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
