[dns-privacy] draft-ietf-core-dns-over-coap-01 (was [DNSOP] [core] WGA call for draft-lenders-dns-over-coap)

[Martine Sophie Lenders <[e-mail]>]

Hello Ben,

Thanks for the feedback! We will account for that in the next version of 
the DoC draft (-02) ASAP.

Some discussion regarding the ALPN ID (3) already started here: 
https://github.com/core-wg/draft-dns-over-coap/issues/22, something 
similar for OSCORE might also be required.

Best
Martine

On 24.10.22 22:12, Ben Schwartz wrote:
> Thanks for this update.  I think the DoC draft is much improved by this 
> separation.
> 
> On DoC:
> 
> 0. Why isn't DoH via CoAP gateway sufficient?  The draft should 
> explain.  If the answer is message size overhead, please put a number on it.
> 
> 1. The TTL rewriting proposed here is notably different from DoH.  I 
> think I understand the reason for the divergence but it's not explained 
> in the draft.
> 
> 2. Does DoC live at a URI path?  I assume it does, but I couldn't tell 
> from the draft.  If so, consider defining a default path, if this is a 
> common practice in CoAP.  In HTTP, default paths are generally 
> forbidden, so DoH doesn't have one.  This has been inconvenient.
> 
> 3. I recommend adding a section describing how to bootstrap DoC in a 
> SVCB-DNS record.  I think this may require you to allocate a new ALPN ID 
> for CoAP/DTLS (e.g. "coap-dtls").
> 
> --------
> 
> I don't think the "compact DNS" proposal is worthwhile, at least in the 
> current framing.  The normal DNS message format is already quite well 
> optimized for compactness, and recursive resolvers rarely return 
> something that is unlikely to be useful.  I think this draft would have 
> a really minimal impact on the typical message size distribution.  Also, 
> DNS is typically used to bootstrap something else, so a small savings in 
> DNS overhead becomes negligible for the system as a whole.
> 
> The draft also seems to contain a misconception about what is optional 
> in CNAME handling: there is no situation in which a stub resolver will 
> chase a CNAME chain.  That is always the recursive resolver's job.
> 
> On Mon, Oct 24, 2022 at 2:25 PM Martine Sophie Lenders 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hi!
> 
>     Am 21.09.22 um 21:31 schrieb Ben Schwartz:
>      > Preparing a separate document on compact DNS seems like a fine
>     start to me.
> 
>     We just published Version -01 of the draft [1]. The most significant
>     change in regard to this discussion is that Section 5.1 was now
>     moved to
>     its own draft [2]. We are happy to discuss this, e.g., in the DNSOP WG
>     meeting or F2F during a break at IETF 115, if the WG meeting agenda
>     does
>     not allow for this anymore.
> 
>     The full listing of changes to the DoC draft can be found in Appendix A
>     of [1].
> 
>     Cheers
>     Martine
> 
>     [1]
>     https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/01/
>     <https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/01/>
>     [2] https://datatracker.ietf.org/doc/draft-lenders-dns-cns/
>     <https://datatracker.ietf.org/doc/draft-lenders-dns-cns/>
> 
>      >
>      > On Wed, Sep 21, 2022 at 4:32 AM Martine Sophie Lenders
>      > <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>> 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=[e-mail]
>     <mailto:[e-mail]>>
>      >>>     <mailto:bemasc <mailto:bemasc>=[e-mail]
>     <mailto:[e-mail]>> 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
>      >>>     <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>> 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 <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
>     <[e-mail] <mailto:[e-mail]>
>      >>>>         <mailto:[e-mail] <mailto:[e-mail]>>> 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 <https://github.com/core-wg>
>     <https://github.com/core-wg <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/
>     <https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/> 
>     <https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/
>     <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 list
>      >>>>> [e-mail] <mailto:[e-mail]>  <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >>>>> https://www.ietf.org/mailman/listinfo/core
>     <https://www.ietf.org/mailman/listinfo/core> 
>     <https://www.ietf.org/mailman/listinfo/core
>     <https://www.ietf.org/mailman/listinfo/core>>
>      >>>>
>      >>>>             --
>      >>>>             Jaime Jiménez
>      >>>>
>      >>>>             _______________________________________________
>      >>>>             DNSOP mailing list
>      >>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >>>> https://www.ietf.org/mailman/listinfo/dnsop
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>      >>>>             <https://www.ietf.org/mailman/listinfo/dnsop
>     <https://www.ietf.org/mailman/listinfo/dnsop>>
>      >>>>
>      >>>>
>      >>>>         _______________________________________________
>      >>>>         core mailing list
>      >>>> [e-mail] <mailto:[e-mail]>  <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >>>> https://www.ietf.org/mailman/listinfo/core
>     <https://www.ietf.org/mailman/listinfo/core> 
>     <https://www.ietf.org/mailman/listinfo/core
>     <https://www.ietf.org/mailman/listinfo/core>>
>      >>>
>      >
>      >     ____ _______________________________________________
>      >     DNSOP mailing list
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/dnsop
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>      >     <https://www.ietf.org/mailman/listinfo/dnsop
>     <https://www.ietf.org/mailman/listinfo/dnsop>>
>      >
>