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
