Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-05.txt

"Wessels, Duane" <dwessels@verisign.com> Wed, 04 December 2019 22:22 UTC

Return-Path: <dwessels@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 0DF4B12002F for <dnsop@ietfa.amsl.com>; Wed, 4 Dec 2019 14:22:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 36eOIDAKrdgQ for <dnsop@ietfa.amsl.com>; Wed, 4 Dec 2019 14:22:24 -0800 (PST)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 1F860120033 for <dnsop@ietf.org>; Wed, 4 Dec 2019 14:22:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=10222; q=dns/txt; s=VRSN; t=1575498145; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=UgKZbm88B2+t/YZc8mvLS6CZclLEJ0sgtiwFd5Orzrs=; b=duzcPxV2W/YnrPdi9fVD9SdcBxXMP1Dpsi7aklaD7yoKY5sVBchv8AwI 4JGH3lQMVTaHCOh2hJRAIj0EXNjeVuMFNx0HcPJ8BezVpEkmZpvsKoiz0 KBwqozzARW/2vtkA8PVz8tsNePzBhhksnS5SouJh8iQcNijxo6BDaRH/p h4TQeyqscL2okdHBLkLhlCYz06WOmcwhCL3ZNDHoZix6lPT79DxNivcQ/ D8S2wzrPuTB7cbxk5xhLAj4AchPGVqlkQbssDhvIk89Yq5DrbJFEI+6eE 0mZItpd0FfPisdJsniYwo3xqBBXQt196LZxfqJLg5LDncoAxn3Msx9+vP Q==;
IronPort-SDR: Ugil65DaxhZXMaXvaLquTmljImi3OLqJVmjkvRtOb88D0cOc5nN3IYp09YH9Y9zlevEOm5ogbb Z9o56L6jcUgZG1YuTHKUQGxWxS5JTCFyajWKTI5hoRdhyvrdvbQLMleRmbKPsqB6jQrKVGKsiQ vYTHce5pYN5PwR9ytflZkL5IdPIZAB6UiZHhJnkeA1mRuZ9myC2k5bga+HA2FqTahvuU20Cu9c cvTeFa+onXkMP9Q8/4+WOoA6pWvBWKnslfabzZ9GsbJoV7G2q9U3vZMgej1Li9co7lQA1YX9jE 7B8=
X-IronPort-AV: E=Sophos;i="5.69,278,1571716800"; d="p7s'?scan'208";a="189052"
IronPort-PHdr: =?us-ascii?q?9a23=3AClcXSxfRqHBMikPYDVsQFdUllGMj4u6mDksu8p?= =?us-ascii?q?Mizoh2WeGdxcWyZR7h7PlgxGXEQZ/co6odzbaP6Oa5Bj1LuMve+Fk5M7V0Hy?= =?us-ascii?q?cfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFR?= =?us-ascii?q?rwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAi4oAnLq8Ubg49vJqksxh?= =?us-ascii?q?bJoHZDZvhby35vKV+PhRj3+92+/IRk8yReuvIh89BPXKDndKkmTrJWESorPX?= =?us-ascii?q?kt6MLkqRfMQw2P5mABUmoNiRpHHxLF7BDhUZjvtCbxq/dw1zObPc3ySrA0RC?= =?us-ascii?q?ii4qJ2QxLmlCsLKzg0+3zRh8dtjqxUvQihqgR/zYDKfY+VKPRwcKDTfdwYQm?= =?us-ascii?q?RBX9peWCNaD4Ozc4cPCvAMPeZEo4XjoVYFsBuwBROrBOPq0jJEiH/50rMh0+?= =?us-ascii?q?Q6Dw7G2BcgE8oTu3rasdX6LqESXv67wKLVyjjMcv1X1inm6IjTbB8hpeqMUK?= =?us-ascii?q?luccXP00kvFhjFjlSfqYzjJT+ayuMNs22C4udmSOmhhWknqwRrrTiuwMchko?= =?us-ascii?q?jJiZwJylDK7yl5x5w1JdK+RUVmYtCkCINduzyGO4dsX88vQW9ltDwnxrAGt5?= =?us-ascii?q?O3ZicHxZA/yxLCd/CLaZWE7xD/WOqLPDt1i3FodKiiixux6USgxPPzW8qo3F?= =?us-ascii?q?tPqydKiNrBu3QW2BHW5MWLVOZy80ak1DmU0w3e6+NJLEU6mKfVKZMu37g9nY?= =?us-ascii?q?cJv0vZBC/5gkD2gbeTdkUj5+en9fzqYq7jpp+AL490jRz+Mrg2lsy/H+s4Ng?= =?us-ascii?q?8OUnCG9OqgzLPv4E32Tq1FgPI3jqXVrorWJdoHqa6+GQ9Vypwv5AyiADu8zt?= =?us-ascii?q?QYh2IHLFRfdB2biIjpPknCIPH+Dfihn1ShiCpny+zcMrH8AJjAIGLPnKrhcL?= =?us-ascii?q?tz8UJRxw4+wcha551OC7EBJPzzWlX2tNzdFhI2LgK1zPj8CNVmyIweXXmPD7?= =?us-ascii?q?SHMKzMq1+I5/kvI+iDZI8TojryN/8l5/v2gX8jhVAdZbWp3YcQaH2gBvRmPk?= =?us-ascii?q?OZbmTyjdcdCmcHpgUzQPDliF2FVj5TaHKyULwm6j4nD4KmCJzOSZ2ogLObxi?= =?us-ascii?q?e0AodaZmFYBVCQH3fkbYKEW+0DaCiKOM9ujiQEVaS9S48mzRyhqQn6y6FgLu?= =?us-ascii?q?rM4SAYtIzs1MR75+HJkhEy7zN0XIyh1DS1Umd5k39AfDgx0OgruVF7x1qfyv?= =?us-ascii?q?0k2/NfEtNX6rVCVQISOZvV1ec8Ct3uVETGZNjfG3i8RdDzSw48Vck8x8RKK2?= =?us-ascii?q?pgEtOvxFiX0zWnGKQYk6ejGpEu87nd0H63LMF4nSWVnJI9hkUrF5McfVatgb?= =?us-ascii?q?RyolDe?=
X-IPAS-Result: =?us-ascii?q?A2F7AACrMOhd/zGZrQplGgEBAQEBAQEBAQMBAQEBEQEBA?= =?us-ascii?q?QICAQEBAYF+gwwrgQYKlR0lg2yXQQkBAQEBAQEBAQEDBAElCgEBAoQ+AoI1O?= =?us-ascii?q?BMCAwEBCwEBAQQBAQEBAQUDAQEBAoYgDII7ImtrAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARYCQ1USAQEdAQEBAQIBeQULAgEIGC4CMCUCBA4FDoMUAYJXER6wE4Inh?= =?us-ascii?q?U+EZwoGgTaBU4NJhxWBQj6BOAwUgkw+gmQCAhqBIRAVg0OCLASNLJILjxMDB?= =?us-ascii?q?4Iug1KCNYEYhSeJL5omlwuOQ4MfAgQCBAUCFYFpgXtwFRohKgGCQT4SERSVb?= =?us-ascii?q?YU/dAGPJ4EwgRABAQ?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 4 Dec 2019 17:22:41 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1779.002; Wed, 4 Dec 2019 17:22:41 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Puneet Sood <puneets=40google.com@dmarc.ietf.org>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-05.txt
Thread-Index: AQHVqvFXMuxK5P0jQU21V51Tyt6pmw==
Date: Wed, 4 Dec 2019 22:22:41 +0000
Message-ID: <C0F7012B-1C1B-4258-99FD-A07F81337874@verisign.com>
References: <157271808929.6094.7926587135820341966@ietfa.amsl.com> <D608BC6F-AD66-4A2A-AE4A-2D306F7FC05E@verisign.com> <CA+9_gVvmOPjcM5Kfe65iGNXgj87_SXYibxF=5mZXpuQc7_WUWw@mail.gmail.com>
In-Reply-To: <CA+9_gVvmOPjcM5Kfe65iGNXgj87_SXYibxF=5mZXpuQc7_WUWw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.9.1)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_0B996E60-A6C5-4808-B09F-E7EA731242EE"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2YJeVgvSQrqhyE5hvUNxdglouxE>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-05.txt
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: Wed, 04 Dec 2019 22:22:26 -0000


> On Dec 2, 2019, at 9:38 PM, Puneet Sood <puneets=40google.com@dmarc.ietf.org>; wrote:
> 
> On Sat, Nov 2, 2019 at 2:18 PM Wessels, Duane
> <dwessels=40verisign.com@dmarc.ietf.org>; wrote:
>> 
>> Hello dnsop,
>> 
>> This draft has been updated with the following changes since -04:
>> 
>> - added DNS-over-TLS to the abstract
>> - added recent discussions about avoiding fragmentation in DNS
>> - changed "SHOULD use TFO" to "MAY use TFO" due to concerns expressed in the WG
>> - changed discussion of KSK rollover to past tense
>> - added privacy consideration text
>> - added a few new references
>> 
>> The authors would like to take this draft to working group last call.
> 
> General comment: I do not see much discussion of this draft on the
> list (https://mailarchive.ietf.org/arch/search/?q=%22draft-ietf-dnsop-dns-tcp-requirements%22),
> The longest thread is about the semantics of DNS flag days and their
> (lack of) benefit. Personally I find the appendix very useful since it
> pulls together all relevant RFCs.

Thanks for the feedback.

> 
> Specific comments below.
> 
> COMMENT: Section 5.1 DNS Wedgie
> This is an issue for a resolver. Could we add a recommendation to
> section 4.2 "Connection Management" for resolvers to handle this
> better?
> Something along the lines of "A resolver MAY want to track and limit
> the number of TCP connections it opens to a single nameserver.".

I agree this was missing.  Since this is about establishing connections, I
updated the title of section 4.1 and added this new paragraph:

4.1.  Connection Establishment and Admission

   Resolvers and other DNS clients should be aware that some servers
   might not be reachable over TCP.  For this reason, clients MAY want
   to track and limit the number of TCP connections and connection
   attempts to a single server.  Additionally, DNS clients MAY want to
   enforce a short timeout on unestablished connections, rather than
   rely on the host operating system's TCP connection timeout, which is
   often around 60-120 seconds.


> COMMENT: Section 5.3 DNS-over-TLS seems out of place in section 5. It
> would fit better in section 4. Network and System Considerations.

Moved.

> 
> COMMENT: Section 6 Logging and Monitoring
> Use some SHOULD keywords to make the recommendations stronger.

Done.

   Developers of applications that log or monitor DNS SHOULD NOT ignore
   TCP due to the perception that it is rarely used or is hard to
   process.  Operators SHOULD ensure that their monitoring and logging
   applications properly capture DNS message over TCP.  Otherwise,
   attacks, exfiltration attempts, and normal traffic may go undetected.

   DNS messages over TCP are in no way guaranteed to arrive in single
   segments.  In fact, a clever attacker might attempt to hide certain
   messages by forcing them over very small TCP segments.  Applications
   that capture network packets (e.g., with libpcap [libpcap]) SHOULD be
   prepared to implement and perform full TCP segment reassembly.
   dnscap [dnscap] is an open-source example of a DNS logging program
   that implements TCP reassembly.

   Developers SHOULD also keep in mind connection reuse, query
   pipelining, and out-of-order responses when building and testing DNS
   monitoring applications.


DW