Re: [DNSOP] New version of draft-ietf-dnsop-rfc7816bis after WG last call

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 19 April 2021 12:19 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0DE3A2F4F for <dnsop@ietfa.amsl.com>; Mon, 19 Apr 2021 05:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 vkGKQTjrY0fA for <dnsop@ietfa.amsl.com>; Mon, 19 Apr 2021 05:19:15 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 D24CE3A2F4E for <dnsop@ietf.org>; Mon, 19 Apr 2021 05:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1843; q=dns/txt; s=VRSN; t=1618834755; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/CzFPlwCq7I7XhOohe7dKtW7Ar4jc02+8SrmYK1Kq40=; b=pdg2I/2xmxtT+nD7i2kIgQ6qlLoFd2jNNjRJnM+vK6e/uG8pPeFr7j+K PqIVVJ9fg1vLhZ0Sc/unYN8t1N+minOMCdsONoXpx56Hnvahgltl93b9u tVJLAihnJ4fX72ZLwhBQ6LhcN9ebifrIMGrXTR6U5eTZEiHsrg9wM4PdL MIjIZx7o/brRE8A2Mtb/ZY+qZoixyUxmnwlGhD1+ybl22Hr4gvTUfCHPg OB6H+AifwhWt7N8wa+erR50SAr6HGVeqkEhTISRnw3brbe1NR4luvp+Xx a3xjpOpuMiKqYYAUq1S9T5YSnOcF4sRb5sOo7a/HUHHuZOvPMIIy/a1ex A==;
IronPort-SDR: MYJ7Hc53RNSSmZS1EU/ot2+JClbREMEtkPTUF9xG8XHNyaLK/Ma1i9+Tb2XcSeFu10v4Ks641X /NvSMTU6g3LUJVPhCqru4npG+A6IJOSYucmYfuTud+dopOSkS3F9siG4izFU5tHlKPv6TLAvTS utyJAlh558Qu8p0x1eSVJcJxZP+GbgPZC3oMIS5HHQ/yBAJEcOSgVGVF0CpS4O4SUfLm3TFaMn lbAE7k3BVXk/BRlB0jROb7brI6N0PIgHa3AAvke8IFKvWN3UeishAnaI+m5nwoP7PxL7yU3XN0 AcM=
IronPort-HdrOrdr: A9a23:kr7+eqp9HG3XDClFAy9lSygaV5q8eYIsi2QD101hICF9WMqeis yogbAnzhfykjkcQzUNntqHNamGTxrnhPtIyKMWOqqvWxSjhXuwIOhZnOnf6hDpBiGWzI5g/I h6dawWMrPNJHxbqeq/3wWiCdYnx7C8n5yAvuvVw3dzQQwCUcgJ0y5CFg2ZHkdqLTM2ZqYRKZ z03Kt6jgvlV3gRYt+yG3UJG8PSzuemqLvWJToLHQQu5gXLrz+5gYSRLzGomjMTSSlGz7tny3 XCiACR3Miemuu20QDRzFXe6JlqmN/so+EpOPCx
X-IronPort-AV: E=Sophos;i="5.82,234,1613451600"; d="scan'208";a="6679048"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Mon, 19 Apr 2021 08:19:13 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.2242.008; Mon, 19 Apr 2021 08:19:13 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "paul.hoffman@icann.org" <paul.hoffman@icann.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: New version of draft-ietf-dnsop-rfc7816bis after WG last call
Thread-Index: AQHXMk0xJQDldNE54EqELnRw4ZUHQKq7xypw
Date: Mon, 19 Apr 2021 12:19:13 +0000
Message-ID: <2cb48d1541e8489fa07dd9c01731ec25@verisign.com>
References: <0053F712-2701-42E0-9B7C-8B3A0757210C@icann.org>
In-Reply-To: <0053F712-2701-42E0-9B7C-8B3A0757210C@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QKuuDAsrpEU-aKkglLNMKf4SDGE>
Subject: Re: [DNSOP] New version of draft-ietf-dnsop-rfc7816bis after WG last call
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2021 12:19:20 -0000

> -----Original Message-----
> From: DNSOP <dnsop-bounces@ietf.org> On Behalf Of Paul Hoffman
> Sent: Thursday, April 15, 2021 7:15 PM
> To: DNSOP Working Group <dnsop@ietf.org>
> Subject: [EXTERNAL] [DNSOP] New version of draft-ietf-dnsop-rfc7816bis
> after WG last call
>
> Greetings again. We have posted a very delayed version draft-ietf-dnsop-
> rfc7816bis that we believe answers all of the issues brought up during WG
> last call. There are a lot of significant changes from the previous version.
>
> Everyone (but particularly resolver developers): please review the document
> carefully, particularly the algorithm in Section 3, to see if it matches what you
> expect.

Thanks for the update! I have a few minor suggestions after re-reading the draft.

Section 1.1: "Academic research has been performed on QNAME minimisation [devries-qnamemin].  This work shows that QNAME minimisation in relaxed mode causes almost no problems." It would be helpful to note the issues that the paper described, perhaps as follows:

"This work shows that QNAME minimisation in relaxed made causes almost no problems; some of the issues that have been observed are described in Section 5."

Section 5: It's worth noting the performance issues reported in [devries-qnamemin]. Suggestion:

OLD:
QNAME minimisation can increase the number of queries based on the incoming QNAME.  This is described in Section 2.3.

NEW:
QNAME minimisation can increase the number of queries based on the incoming QNAME.  This is described in Section 2.3. As described in [devries-qnamemin], QNAME minimisation in strict mode both increases the number of DNS lookups by up to 26% and leads to up to 5% more failed lookups. The full cache in a production resolver will soften that overhead.

Scott