On 20. Sep 2022, at 17:12, Ben Schwartz
<bemasc=40google....@dmarc.ietf.org>
<mailto: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 <mailto: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
<mailto: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 <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/>
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 <mailto:c...@ietf.org>
https://www.ietf.org/mailman/listinfo/core
<https://www.ietf.org/mailman/listinfo/core>
--
Jaime Jiménez
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org <mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
core mailing list
c...@ietf.org <mailto:c...@ietf.org>
https://www.ietf.org/mailman/listinfo/core
<https://www.ietf.org/mailman/listinfo/core>
