Re: [DNSOP] SVCB without A/AAAA records at the service name

"Hollenbeck, Scott" <shollenbeck@verisign.com> Mon, 25 January 2021 13:05 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 A8C653A11B8 for <dnsop@ietfa.amsl.com>; Mon, 25 Jan 2021 05:05:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 e48hMG3UBp4J for <dnsop@ietfa.amsl.com>; Mon, 25 Jan 2021 05:05:52 -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 6E23B3A11B9 for <dnsop@ietf.org>; Mon, 25 Jan 2021 05:05:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=13754; q=dns/txt; s=VRSN; t=1611579953; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=OLwjmHaVM/fzXbLZSKLuXWfLwo6A42m3zZr+yfv/7jw=; b=PacP8Nw895aQltXdWAHnof6O3WjlT0xOPRpuQwVaEedxBvFhyeuTPr/+ 7+RZzH6QciCTcN717Z0F5H9vmrXka1xum/3bSwGDb2JKAo6aL1k5umKhu u7nOQvz5PXnPIWLRs9Kf6TnWUCCQ6pqKET6o2mXEPzoIzg9tCDfTdbe0k kIWzc57EF295giH2qqGRESEZkczyNk6xc5CK22MkT3jTzZYdBrMkcr/V0 0/OXLG1m7nPJ+rBe5j7Lry7uxkOB1d3WSYr03GOzKa5ZkBmlm6XWSgDCV Cao2tEk+78kEJ6Ba3WRyaRdiXsQomjmeemykJKqrmDzzGpws0U43oqck8 g==;
IronPort-SDR: LUULAQ7HvBU1aCimDv2iOBhf5cPqEb5bSAgnCGOB94JZEep5od7kiIWFHRMIEfHe8P9uHbpQn0 D+71wW0OrSONbcvg5+enSm6Qa9PnoTvl4YIotoh+qY5SZ7ic0STYWCxKuJ69X7/EhwBTJXChX3 8ZvK44WI3KhYAFPzwyaHgcQ42L9jsabz4ipgxg2ugLq0rv7KmY4YRmQdyupiQwgKs/7APxiFZ3 NrO6jpEby4mozb+qtBJzmF1zMocSuWeEFIJ6QK1FgmRhhbeIo82P0WqAaWhdmMcjvEEhkAiJ9/ Cco=
X-IronPort-AV: E=Sophos;i="5.79,373,1602561600"; d="scan'208,217";a="4741486"
IronPort-PHdr: 9a23:9WU21xLEg9WWYH80X9mcpTZWNBhigK39O0sv0rFitYgXK/z8rarrMEGX3/hxlliBBdydt6sVzbCN+Py8ESxYuNDd6S9EKMQNHzY+yuwu1zQ6B8CEDUCpZNXLVAcdWPp4aVl+4nugOlJUEsutL3fbo3m18CJAUk6nbVk9Kev6AJPdgNqq3O6u5ZLTfx9IhD2gar9uMRm6twrcutQSjId4NKo8xBTFr3RHdu9LwW9kOU+fkwzz68ut/pNv6Thct+4k+8VdTaj0YqM0QKBCAj87KW41/srrtRfCTQuL+HQRV3gdnwRLDQbY8hz0R4/9vSTmuOVz3imaJtD2QqsvWTu+9adrSQTnhzkBOjUk7WzYkM1wjKZcoBK8uxxyxpPfbY+JOPZieK7WYNUXTndDUMlMTSxMGoOyYZUSAeodM+hWrIf9qFkPrRSiCgahH/ngxiNKhnLswaE2z+YsHAfb1wIgBdIOt3HUoc37OKkQVuC1yK3IwivFb/xNxzjy9IvIfgg8qv+RQb1wdtbRyVUhGwjYiViQsozlPzSR1uQJrWeb6fFvWvyzhG4ksAxxvCagxt0tionSh4IVxVbE+T9lz4YyIN21UUh2asOrH5VMrS+VLZd2Qt88TGFyviY30qMLtIKmcCYEy5kqxQLTZv2bf4WK7BztW+ScLDR2iX9rZL+ymwi+/Eikx+PzV8S531ZHozdLnNXRuX4D2B7e59WBR/Bg/UmhwS6C2x3P5u1ePEw5l6TWJ4Q8zrMwmJcfq0vOEyzulEnrkKOabFgo9+q05+j9f7nrqZyRO5Vphgz9NKklh9axDv4iMgcUWmiW4eG81Lr+8kLnWLhKlfg2krXBsJDdOMQbura1Aw9L3YYn7BayFyqr3sgAk3UaLF1LYB2JgIn1N13TOvz4E+uwg1O2kDdz3fzJJKDuDo/TLnjZi7fhe6xx5FJbyAo21dxf5pRUBa8dIP/rR0P9qMbUAgI7PgG62errFdVw240EVW+AAaKVKKbSvkWJ5uIrLemMfogVuDPlJvg+5/7uins5mVsDcqmvxpQYdmy3Hvd9LkWHf3XsmNYBEXwLvgoxSuzmkkGNUTlWZ3qqRaIz+ik7CJ66DYfEXo2im6KO3CKhEZ1Nem9LEl+BHWvnd4WDXPcMZyaSLdF7njMYUrihTpQs2gyrtADg0bpoMvDY+iwGupL/2th5/erTlQs99TZsFcSSz3mNT31onmMPXzI22bx/rFd5yleE36l3nfpYFcBJ5/NOSgc7NYTQz+pkBNDuQgjBZMuGSE66QtW6BjE8Vs8+w9kVY0Z6A9WvlRHD0DS2A78bjbCLA4Y08q2Pl0T2cox3xnPPz6J00wEpRcxAMWDgjal63wTWDpTC1USUi6jscr4TlmaZ/mqGxHGF6R0AXwl3XqHIG3sYY2PaqN3j7QXDQqOgT7M9PV0S59SFL/4AStrtiVhATvroO5CWWGm2h3v6TUKTxrSIaIfscWgW3w3DBVIFiAEc+zCNMg1oVXTpmH7XEDE7TQGnWEjr6+Qr8H4=
X-IPAS-Result: A2FYAAAUwQ5g/zCZrQpiHQEBAQEJARIBBQUBgXwHAQsBgSJTgSuBOQqENpFZA5pFgXwLAQEBAQEBAQEBCAEvBAEBhEoCF4FjJjUIDgIDAQELAQEBBQEBAQEBBgMBAQEChk8Lgjgig3YBAQEBAyMKTBACAQgRBAEBAScDAgICMBQJCAIEDgUIgx+BfrMjdoEyhVmFBoE4AYZ6AYZCQYFCPoERgxk+gl0EgXQfgmOCYASDb4EVE1McKjKPY4MlhzUrnVADB4J3m2YroniPJYR5nQSEUgIEAgQFAhaBVwGCEHCDOVAXAg2canQCNQIGCgEBAwmLBIERAQE
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.2106.2; Mon, 25 Jan 2021 08:05:50 -0500
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.2106.006; Mon, 25 Jan 2021 08:05:50 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "bemasc=40google.com@dmarc.ietf.org" <bemasc=40google.com@dmarc.ietf.org>
CC: "mt@lowentropy.net" <mt@lowentropy.net>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] Re: Re: [DNSOP] SVCB without A/AAAA records at the service name
Thread-Index: AQHW8OyIDggB37R8cku4ReDoBDHrpqo4UvFA
Date: Mon, 25 Jan 2021 13:05:50 +0000
Message-ID: <3e819f32679c403489b4b01968159acf@verisign.com>
References: <2e1054a0-5a7a-4d62-92a1-095217af82bb@www.fastmail.com> <CAHbrMsCaVER+xDjznjRK4cSjqc+g855GNV2QCfewvCqh=E1FMw@mail.gmail.com> <87098be5-765c-4481-b990-bdb2c936173d@www.fastmail.com> <CAHbrMsCu1bYcEuT2R3g5M9aUBQguVeWhiyZpDH=JzSEPpc=iqg@mail.gmail.com> <45895deb-7432-4ad7-bede-107bf6e1973e@www.fastmail.com> <CAHbrMsDFuKNMrvi03VjK_eSio5N1w6eAtRpOMx3NdSYu-f_5Yg@mail.gmail.com> <4b59e60b-f8b0-493b-97b2-210d5541a19d@www.fastmail.com> <CAHbrMsD0ZAXX034b952rPM=3M6D2Ea_m373OmJQeOqqkTPvBPg@mail.gmail.com> <5e619af2c4834afb8ec687e13b8f042e@verisign.com> <CAHbrMsCaCOrqXqBYx3iEbXsSXSJFdiHWw+pDNz7YS_Ahb_-UyA@mail.gmail.com>
In-Reply-To: <CAHbrMsCaCOrqXqBYx3iEbXsSXSJFdiHWw+pDNz7YS_Ahb_-UyA@mail.gmail.com>
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: multipart/alternative; boundary="_000_3e819f32679c403489b4b01968159acfverisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/f9ggW0Llv1-Qm00eskL_KtjM8II>
Subject: Re: [DNSOP] SVCB without A/AAAA records at the service name
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, 25 Jan 2021 13:05:55 -0000

From: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Sent: Friday, January 22, 2021 1:29 PM
To: Hollenbeck, Scott <shollenbeck@verisign.com>
Cc: mt@lowentropy.net; dnsop@ietf.org
Subject: [EXTERNAL] Re: Re: [DNSOP] SVCB without A/AAAA records at the service name







On Fri, Jan 22, 2021 at 12:43 PM Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org<mailto:40verisign.com@dmarc.ietf.org>> wrote:

   From: DNSOP <dnsop-bounces@ietf.org<mailto:dnsop-bounces@ietf.org>> On Behalf Of Ben Schwartz
   Sent: Tuesday, January 19, 2021 10:01 PM
   To: Martin Thomson <mt@lowentropy.net<mailto:mt@lowentropy.net>>
   Cc: dnsop <dnsop@ietf.org<mailto:dnsop@ietf.org>>
   Subject: [EXTERNAL] Re: [DNSOP] SVCB without A/AAAA records at the service name







   On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson <mt@lowentropy.net<mailto:mt@lowentropy.net>> wrote:

      On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote:
      > As I noted in that discussion, the client generally doesn't know in
      > advance that they aren't needed.

      I am asserting that the client very much knows.  Indeed, it has to know.  If we define a new protocol that relies on SVCB and that protocol is able to use SVCB exclusively (which would be a good thing in my view, all this parallel DNS querying is unnecessary, even if the DNS protocol is pretty good at it), then a client can very much know.



   Querying in parallel is of course just an optimization, but the client can't obviously know that those queries won't be needed, even for a protocol that uses SVCB exclusively.



   Every SVCB mapping ultimately relies on A/AAAA records for the ServiceMode TargetName.  The client doesn't know what that TargetName will be until it gets the SVCB response.  However, in every protocol considered thus far, the most likely TargetName is the original hostname (or its CNAME alias).  By querying that name in parallel, the client can short-circuit a subsequent lookup and reduce latency.  This has nothing to do with fallback.



   [SAH] We need to think about the impact on the servers that have to respond to those queries, too. Sending unnecessary queries to the root and TLD servers puts a load on those servers that can have an impact on every client/resolver that needs to be able to reach them.



   This is important, but I don't think it's applicable here.  The various options under consideration all impose the same amount of load on root and TLD servers.

   [SAH] So if some number if queries X and some number of queries Y are processed in parallel, the value of X + Y will be the same as if those queries are processed serially?



   Scott