Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

Qin Wu <bill.wu@huawei.com> Sat, 18 September 2021 06:47 UTC

Return-Path: <bill.wu@huawei.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 E4EC63A0972; Fri, 17 Sep 2021 23:47:09 -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=unavailable 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 vhAA0iuoN0O8; Fri, 17 Sep 2021 23:47:05 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E31E3A0975; Fri, 17 Sep 2021 23:47:05 -0700 (PDT)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HBLs925znz67HxV; Sat, 18 Sep 2021 14:44:29 +0800 (CST)
Received: from dggeml701-chm.china.huawei.com (10.3.17.134) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Sat, 18 Sep 2021 08:47:01 +0200
Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml701-chm.china.huawei.com (10.3.17.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Sat, 18 Sep 2021 14:47:00 +0800
Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2308.008; Sat, 18 Sep 2021 14:47:00 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "draft-ietf-dnsop-dns-tcp-requirements.all@ietf.org" <draft-ietf-dnsop-dns-tcp-requirements.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
Thread-Index: AdesViyqJfzXf9aHQ/+0AZ5ASVW6mA==
Date: Sat, 18 Sep 2021 06:47:00 +0000
Message-ID: <d17753b940ef4f62bb039ebb785bbfde@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.123.117]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/h3lLq64ZYd6b12kEGBFThTGBXe4>
Subject: Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
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: Sat, 18 Sep 2021 06:47:10 -0000

>>On Sep 18,2021,at 3:47 PM, Wessels Duane<dwessels@verisign.com> wrote:
>>4.5.  Defaults and Recommended Limits
>>   
>>   Most open sorcue DNS server implementations provide a configurable
>>   limit on the total number of established connections.  Default values
>>   range from 20 to 150.  In most cases, where the majority of queries
>>   take place over UDP, 150 is a reasonable limit.  For services or
>>   enviroments where most queries take place over TCP or TLS, 5000 is a
>>   more appropriate limit.
>>
>>   Only some open source implementations provide a way to limit the
>>   number of connections per source IP address or subnet, but the
>>   default is to have no limit.  For environments or situations where it
>>   may be neccessary to enable this limit, 25 connections per source IP
>>   address is a reasonable starting point.  The limit should be
>>   increased when aggregated by subnet, or for services where most
>>   queries take place over TCP or TLS.
[Qin]: Defaults and Recommended Limits is interesting, I assume it aligns with the guidelines in section 6.2 of RFC7766
I am wondering whether the total number of established connections is referred to the number of concurrent connections? Come from a single client or multiple clients?

I am a little bit surprised that the connection number limit for DNS over UDP is much less than one for DNS over TCP?
Since I think UDP can support many more client at the same time due to the lack of connection state, can you clarifies the rationale behind,
Thanks.