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: 9a23:ClcXSxfRqHBMikPYDVsQFdUllGMj4u6mDksu8pMizoh2WeGdxcWyZR7h7PlgxGXEQZ/co6odzbaP6Oa5Bj1LuMve+Fk5M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFRrwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAi4oAnLq8Ubg49vJqksxhbJoHZDZvhby35vKV+PhRj3+92+/IRk8yReuvIh89BPXKDndKkmTrJWESorPXkt6MLkqRfMQw2P5mABUmoNiRpHHxLF7BDhUZjvtCbxq/dw1zObPc3ySrA0RCii4qJ2QxLmlCsLKzg0+3zRh8dtjqxUvQihqgR/zYDKfY+VKPRwcKDTfdwYQmRBX9peWCNaD4Ozc4cPCvAMPeZEo4XjoVYFsBuwBROrBOPq0jJEiH/50rMh0+Q6Dw7G2BcgE8oTu3rasdX6LqESXv67wKLVyjjMcv1X1inm6IjTbB8hpeqMUKluccXP00kvFhjFjlSfqYzjJT+ayuMNs22C4udmSOmhhWknqwRrrTiuwMchkojJiZwJylDK7yl5x5w1JdK+RUVmYtCkCINduzyGO4dsX88vQW9ltDwnxrAGt5O3ZicHxZA/yxLCd/CLaZWE7xD/WOqLPDt1i3FodKiiixux6USgxPPzW8qo3FtPqydKiNrBu3QW2BHW5MWLVOZy80ak1DmU0w3e6+NJLEU6mKfVKZMu37g9nYcJv0vZBC/5gkD2gbeTdkUj5+en9fzqYq7jpp+AL490jRz+Mrg2lsy/H+s4Ng8OUnCG9OqgzLPv4E32Tq1FgPI3jqXVrorWJdoHqa6+GQ9Vypwv5AyiADu8ztQYh2IHLFRfdB2biIjpPknCIPH+Dfihn1ShiCpny+zcMrH8AJjAIGLPnKrhcLtz8UJRxw4+wcha551OC7EBJPzzWlX2tNzdFhI2LgK1zPj8CNVmyIweXXmPD7SHMKzMq1+I5/kvI+iDZI8TojryN/8l5/v2gX8jhVAdZbWp3YcQaH2gBvRmPkOZbmTyjdcdCmcHpgUzQPDliF2FVj5TaHKyULwm6j4nD4KmCJzOSZ2ogLObxie0AodaZmFYBVCQH3fkbYKEW+0DaCiKOM9ujiQEVaS9S48mzRyhqQn6y6FgLurM4SAYtIzs1MR75+HJkhEy7zN0XIyh1DS1Umd5k39AfDgx0OgruVF7x1qfyv0k2/NfEtNX6rVCVQISOZvV1ec8Ct3uVETGZNjfG3i8RdDzSw48Vck8x8RKK2pgEtOvxFiX0zWnGKQYk6ejGpEu87nd0H63LMF4nSWVnJI9hkUrF5McfVatgbRyolDe
X-IPAS-Result: A2F7AACrMOhd/zGZrQplGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF+gwwrgQYKlR0lg2yXQQkBAQEBAQEBAQEDBAElCgEBAoQ+AoI1OBMCAwEBCwEBAQQBAQEBAQUDAQEBAoYgDII7ImtrAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAQEdAQEBAQIBeQULAgEIGC4CMCUCBA4FDoMUAYJXER6wE4InhU+EZwoGgTaBU4NJhxWBQj6BOAwUgkw+gmQCAhqBIRAVg0OCLASNLJILjxMDB4Iug1KCNYEYhSeJL5omlwuOQ4MfAgQCBAUCFYFpgXtwFRohKgGCQT4SERSVbYU/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, 04 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
- [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requ… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-… Wessels, Duane
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-… Giovane Moura
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-… Puneet Sood
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-… Wessels, Duane
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-… Paul Vixie
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-… Wessels, Duane