[core] Feedback on DNS over CoAP - draft-lenders-dns-over-coap

Martine Sophie Lenders <m.lenders@fu-berlin.de> Wed, 01 September 2021 11:52 UTC

Return-Path: <mlenders@zedat.fu-berlin.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510E33A08E6 for <core@ietfa.amsl.com>; Wed, 1 Sep 2021 04:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDK_3eBUF1sO for <core@ietfa.amsl.com>; Wed, 1 Sep 2021 04:52:37 -0700 (PDT)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEED3A08D7 for <core@ietf.org>; Wed, 1 Sep 2021 04:52:36 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.94) for core@ietf.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from <mlenders@zedat.fu-berlin.de>) id 1mLOnA-001fSB-Lf; Wed, 01 Sep 2021 13:52:32 +0200
Received: from [5.61.188.191] (helo=[192.168.101.6]) by inpost2.zedat.fu-berlin.de (Exim 4.94) for core@ietf.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (envelope-from <m.lenders@fu-berlin.de>) id 1mLOnA-001X9Z-Eo; Wed, 01 Sep 2021 13:52:32 +0200
To: "core@ietf.org" <core@ietf.org>
From: Martine Sophie Lenders <m.lenders@fu-berlin.de>
Message-ID: <23deb329-d20f-21ff-8178-7df494763167@fu-berlin.de>
Date: Wed, 01 Sep 2021 13:52:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Original-Sender: m.lenders@fu-berlin.de
X-Originating-IP: 5.61.188.191
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Eh037wCswJW4uE-wKA1ieq2sUJQ>
Subject: [core] Feedback on DNS over CoAP - draft-lenders-dns-over-coap
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2021 11:52:43 -0000

Dear CoRE-WG,

we would like to present our proposal for DNS over CoAP (DoC):

https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/

DoC allows for the sending of DNS messages over CoAP, using GET, POST,
and FETCH methods. Similar to DoH in the wider Internet, DoC aims for
providing encrypted DNS message exchange but for constrained IoT
devices, utilizing DTLS or OSCORE,

Comments on our proposal are very welcome! Specifically, we would like
to discuss the following items:

1. How should caching hints in DNS (TTL) relate to CoAP (Max-Age) and
vice versa? How should relative times be handled in general when using
caching [1]? Christian Amsüss previously kicked this discussion off on
the CoRE mailing list [2].

2. Should we only specify the usage of FETCH and abandon GET and POST in
DoC [3]?

   (a) GET introduces the disadvantage that all requested data (such as a
DNS query) needs to be carried within the URI, so block-wise transfer is
not possible. Additional overhead occurs since the data needs to be
converted into a URI format.

   (b) POST, on the other hand, does not allow for en-route caching of
successful responses. In contrast to HTTP, however, CoAP provides the
FETCH method, which allows for both adding data to the body of a request
and caching of successful responses.

   (c) There is one concern regarding FETCH. Various CoAP implementations
do not support FETCH [4] (maybe because FETCH was added later to CoAP).
This could hinder deployment of DoC or could lead DoC implementations
that are not spec-compliant, because implementers just use GET or POST
when FETCH is not available.


Looking forward to your feedback!

Thanks,
Martine
on behalf of the co-authors of draft-lenders-dns-over-coap

[1]https://github.com/anr-bmbf-pivot/draft-dns-over-coap/issues/5
[2]https://mailarchive.ietf.org/arch/msg/core/CzRQTARwPgIwJN0s_kmlLRCNMKY
[3]https://github.com/anr-bmbf-pivot/draft-dns-over-coap/pull/8
[4]https://coap.technology/impls.html