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> 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 list
c...@ietf.org
https://www.ietf.org/mailman/listinfo/core
--
Jaime Jiménez
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
core mailing list
c...@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
