[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
- [core] Feedback on DNS over CoAP - draft-lenders-… Martine Sophie Lenders
- Re: [core] Feedback on DNS over CoAP - draft-lend… Carsten Bormann
- Re: [core] Feedback on DNS over CoAP - draft-lend… Martine Sophie Lenders