Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

"Wessels, Duane" <dwessels@verisign.com> Fri, 05 November 2021 17:02 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 F0E0C3A124D; Fri, 5 Nov 2021 10:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8L_6-7Rg02lq; Fri, 5 Nov 2021 10:02:39 -0700 (PDT)
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 BAD9E3A124A; Fri, 5 Nov 2021 10:02:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3298; q=dns/txt; s=VRSN; t=1636131760; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=L1U4Imz4JNnaeNUhJq/6iKwyaWtrpwFRNQGAoE5Y154=; b=cLYkdqik6SDG1m7ecPztxFoHYoylvtjHDN3yHEziWKgbvfGsB/YnZzj1 bsc1DN5yBnxedgog1ktGJ3F7yEReRznSs0F2Bljm9dXZskcTJ5LV5kWO9 sMAOYHXwx/5tBhmYMiG9GtlOpZwm+OaR5YBqFWtaM0aeFlPxaczB0+OoT LaLWn8UQKtlJQ/r/KML0LfA8QRkIoLB2EKKGCZ1froEmQVJMGF5iS/DE8 Ibj9exoajE0A13KC5aXfNemEyLwdw8MMv69UmMtZOZMVjs/6+QtIQCkkU T9o+KXN8AfAlvi9WSIknbs/9mO8FFrT/3J9nY4UQn+mIjW+sfMRh7CzdV Q==;
IronPort-SDR: DDStKvVyizGNQN+8+bbls2SUqDbm5n5QsHHnRm4QGvD2KSkCf8ME66w0aEAQk/WDn8BNUXIPc5 9Z0ZnfETN+Bt21WL9FsBH+M7wPI/L3OYIDo/biqkpupGkpBrwHg2PsCynAJwMR6xAPC5f0DJqh k/8NqBfnDOewUVepbHGmm7Quupkv3wY/KRZ9UcGTjsD+beqJx5f9kQxtV37ge5ZWAbO11l4Ghy nhsz+NTRYLCsaXvDckl964iuw+mOIRQuIIFjt6OdXagcRoTmoNry2tDeR26IpTz12ODx+olOof wfY=
IronPort-Data: A9a23:kyzQhKz7AlPfEh/d8ol6t+ctxyrEfRIJ4+MujC+fZmUNrF6WrkVUz TFKDziCOvzba2bwedgnaYuz/EgPsZbczYNrSQplrS00HyNBpPSeCIXCJC8cHc8ywu4v7a5Dx 59DAjUVBJlsFhcwnvouW1TYhSEUOZugH9IQM8aZfHAuLeNYYH1500s6wrZk2tUAbeWRWGthh /uj+6UzB3f4g1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKEpfNatI88thW5 wr05OrREmvxp3/BA/v7yuqrKhVirrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPh7k P5HrMK6Ez02AaaXtrgnFABDQwBhaPguFL/veRBTsOS59WufTF3B8603Sl89OpcAvO97R39U7 vpeIzcIBvyBr7vuhuvkEa81259lcJmD0IA34xmMyRnVEvs9Wp3HWI3U6MVZxzY/gIZFGvO2i 88xMGIxMk+bM0Un1lE/WLQwwMD02jrGaiAB9mDNoYwL2lni5VkkuFTqGJ+PEjCQfu1YnQCZq 37I12v8CxAecteYzFKt83+3icfOkD/1HoUIG9WQ+uRjjkHWx2EPBlgaU0C8uby1jFX7R9lHb lYZ4zcvt6U3+Uq3VfH8UgG25nmesXY0V9xLFPV/4wGEy7DPyweUGmZCSSROAPQqstQxXRQr2 0OH2dTzClRHq6CHVnWH8ruLrD+/EScQJG4GIyQDSGM4D8LLqps11w3JQ8Y7SeuukMezHDDrh jqN6iIkgexVk9QQ0eOw+lWvby+Qm6UlhzUdvm3/Nl9JJCsgDGJ5T+REMWTm0Ms=
IronPort-HdrOrdr: A9a23:splpba8BmLx+pC2WOXtuk+AFI+orL9Y04lQ7vn2ZLiYlF/Bw9v re/sjzuiWVtN98Yh8dcLO7V5VoKEm0naKdirNhXotKMjOGhEKYaK9v6of4yyDtFmnU5odmuZ tIQuxbBMfrBVZ3yeT38GCDeeoI8Z2i/LqzjenTi01xSxpnApsM0y5iBh2FHlZNSA5KOJo8GP OnjfZ6mw==
X-IronPort-AV: E=Sophos;i="5.87,212,1631592000"; d="scan'208";a="10663380"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) 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.2308.15; Fri, 5 Nov 2021 13:02:35 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2308.015; Fri, 5 Nov 2021 13:02:35 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Erik Kline <ek.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-dnsop-dns-tcp-requirements@ietf.org" <draft-ietf-dnsop-dns-tcp-requirements@ietf.org>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Suzanne Woolf <suzworldwide@gmail.com>
Thread-Topic: [EXTERNAL] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
Thread-Index: AQHXzQelFlbcUDcPp0aRxAYu26Vjbg==
Date: Fri, 05 Nov 2021 17:02:35 +0000
Message-ID: <4B31D334-716B-4859-AD2B-CB530DCDBBAD@verisign.com>
References: <163527893923.7925.10771251146873312518@ietfa.amsl.com> <10A60AEA-0745-4B42-ABD6-24B6A7C83E2D@verisign.com> <CAMGpriUjY2bN+jPgYPOFZXULaEYBtmLSYhBTtO=if=NiO32s6A@mail.gmail.com>
In-Reply-To: <CAMGpriUjY2bN+jPgYPOFZXULaEYBtmLSYhBTtO=if=NiO32s6A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.7)
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D46B1CFEB37AF34BB8D24837EDBA158B@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cS2supDJfGULkOZSKAQVJd-U-T4>
Subject: Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
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: Fri, 05 Nov 2021 17:02:44 -0000


> On Nov 1, 2021, at 3:29 PM, Erik Kline <ek.ietf@gmail.com> wrote:
> 
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
>>> [S4.1, comment]
>>> 
>>> * "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."
>>> 
>>> I think the same comment could be made about paths to a server from
>>> a given network, e.g., in the case of one network filtering TCP/53 for
>>> some reason.
>>> 
>>> I'm not sure how to best reword this to add a per-network notion to
>>> TCP connection success tracking, but I did want to note that a mobile
>>> client's measure of TCP connection success to a single server might
>>> vary from network to network.  (for your consideration)
>> 
>> Is this because mobile devices are more likely to have multiple network choices (say wifi and cellular data) and so the device should include the local network when remembering which works and which doesn’t?
> 
> Yes, they have multiple networks simultaneously and also through time.
> What's reachable/unreachable on one network might not be
> reachable/unreachable on another.  Just moving from one Wi-Fi SSID to
> another can make a difference, e.g.:
> 
>    * imagine two SSIDs that each hand out 8.8.8.8 but have different
> TCP 53 filtering policies, and
> 
>    * (more concretely) I have DNS-over-TLS active on my phone and on
> one nearby coffee shop SSID TCP 853 is blocked while on another
> everything works just fine
> 
> (Hopefully I'm making some kind of sense.)

Thanks Erik, how does this look to you?

       <t>Resolvers and other DNS clients should be aware that some
       servers might not be reachable over TCP.  For this reason, clients
       MAY track and limit the number of TCP connections and
       connection attempts to a single server.  Reachability problems
       can be caused by network elements close to the server, close
       to the client, or anywhere along the path between them.  Mobile
       clients that cache connection failures MAY do so on a per-network
       basis, or MAY clear such a cache upon change of network.</t>

DW