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
<[email protected] <mailto:[email protected]>> 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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
>>> <[email protected]
<mailto:[email protected]>>
>>> <mailto:bemasc <mailto:bemasc>[email protected]
<mailto:[email protected]>> 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
>>> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
<[email protected] <mailto:[email protected]>
>>>> <mailto:[email protected] <mailto:[email protected]>>> 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
>>>>> [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
>>>>> 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
>>>> [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
>>>> 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
>>>> [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
>>>> 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
> [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> 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>>
>
