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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Fri, 22 January 2021 17:43 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 6ABBE3A12CA for <dnsop@ietfa.amsl.com>; Fri, 22 Jan 2021 09:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 OiGwCelv8H2x for <dnsop@ietfa.amsl.com>; Fri, 22 Jan 2021 09:43:30 -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 993CB3A12C1 for <dnsop@ietf.org>; Fri, 22 Jan 2021 09:43:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=10506; q=dns/txt; s=VRSN; t=1611337410; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=UEOt/n80+F/Kk16e2pOCUgAM9CZqOz+6GEg6TEEcc+Q=; b=FjvcIJSeCHgiXP5PASs9nGX3SXtcRGGBss8hQWZCwzCYynHImceI2axD iYoaEyKAH4q8yzvSzNJWUdbo/uGSPUzjhDGrHBKRAhthiRtKuNYbYA0cv wIWsYseNlegpjaPReklFh/emN2ReR/fezZFHAhDW5AhEA8NC2XYDMUOer zyt1ORrN29k4gCn92BhdYEFB2fIsqxMdI2FNEMhnE+q9QqdzZAMNrD+9n jppPOwfAW037Q3gy8hefaEIrwNQgjvlYEoHPDeUkQHKxkskAEH2cI0oar YgGzoydmvgu91Nxd5IWl6p3iyLON6p0PPXySPpoUpPe8XFnZHqmKODYjT A==;
IronPort-SDR: CtTAdCeWpne+y2ohCgLith2QvpCylnN9uzT6he22JPfeeC+VOFjGTi1zTo31GWsPGh82FJ0kTp KfXkDVyTn/kxZuifo4F7fCTaw0uvcQ0wwTSmS9t9YTQ4TSd1x7rNEezlt4NgfwmdMoc2MC5BLN 5qcLGVfYFuLBQgeUC7GM6plhmdZSqlSJ/6IW+kL9jB9Bp1ywnUXjAW82/1D6Ui9189HQ38mjUx xFcHjhH4+o5hW0quFbGQXZ4e5yZ5u3sGjITSyYnUVsNU0BeifegIaaePAstiRZp4HFNxs+ywcI F1w=
X-IronPort-AV: E=Sophos;i="5.79,367,1602561600"; d="scan'208,217";a="4708083"
IronPort-PHdr: =?us-ascii?q?9a23=3A0O0MlBDLhPrgGpjdFK7DUyQJP3N1i/DPJgcQr6?= =?us-ascii?q?AfoPdwSP36rsywAkXT6L1XgUPTWs2DsrQY0ruQ6v6rCTVIoc7Y9ixbL9oUD1?= =?us-ascii?q?5NoP5VtjRoONSCB0z/IayiRA0BN+MGamVY+WqmO1NeAsf0ag6aiHSz6TkPBk?= =?us-ascii?q?e3blItdaz6FYHIksu4yf259YHNbAVUnjq9Zq55IAmroQnLucQanI9vJrwsxh?= =?us-ascii?q?bIrXdFePlazn5sKV6Pghrw/Mi98INh/ihKp/4t68tMWrjmcqolSrBVEC4oOH?= =?us-ascii?q?0v6s3xshnDQwqP5n8CXWgTjxFFHQvL4gzkU5noqif1ufZz1yecPc3tULA7Qi?= =?us-ascii?q?+i4LtxSB/pkygIKTg0+3zKh8NqjaJbpBWhpwFjw4PRfYqYOuZycr/bcNgHQ2?= =?us-ascii?q?dKQ8RfWDFbAo6kb4UBEfcPPfpWoYf+qVsBrxq+ChWjC+700DBEmn320Lcm3+?= =?us-ascii?q?g9EwzL2hErEdIUsHTTqdX4LKkeX+KyzKnMyTXMcfVW1izj54fUcRAtueyHU6?= =?us-ascii?q?9sfsrW1UkvCw3JhUiXpIz+PzOV0eANs2yF4OpmTu2glXIoqwJqrzix2MgskI?= =?us-ascii?q?jJhpkUylDL8yV12po6Jdq9SENiZ9OvDZRfuT2AOYRsXsMiX39nuDw8yrAeup?= =?us-ascii?q?O2YCkHxZA7yxPRafGKboiF7x39WeiRPzt0mW9odK6xihqv7UWtyfDwW8i23V?= =?us-ascii?q?pWoCRIkdfBu3EN2RHd7sWKSv1w9Vqv1zaI0gDc8OBEIUYsmKrFNZEh2L8wlo?= =?us-ascii?q?ESsUTMGC/6gln5jKiTdkgi5+Om6Pznb637qpOALYN4lwPzP6o0lsCiAek1PB?= =?us-ascii?q?ICUmef9OikybHv4Vf1TKhIg/EqiKXVrZ/XKMcBqqKkAAJY1Jso5QylADe8yt?= =?us-ascii?q?sYmGEKLFdCeB2akYfkI0rOIPXkDfenhFSsjStry+jGPrL/BpXNKWDOnar9c7?= =?us-ascii?q?hl9kJTyBI9w99e6J5IFL0NOuzzVVP2tNzCFh81KRa7zPv9BNVjzIMeQmSPDr?= =?us-ascii?q?WFP6PVtF+E/uMvI++Sa48JoDvxNuQp6+TzgXI7l1IRZ7Sl0JsZZXyiEflrJ1?= =?us-ascii?q?2VYX/2jdcAFWcKsBA+TOvviFCaSj5TZ3GyX6Y45j4lDoKpFpnMSZyugLGawi?= =?us-ascii?q?e0AIdWZmFdClCNHnfocZ+IVOsLaCKXOsNhiCALVaC9S4890hGjrBT1xKRiLu?= =?us-ascii?q?XO4S0XqYru2ddp6+3ckhEy8jN0D8CD3G2XU250mWYISiQr06B6u0N90EuM3b?= =?us-ascii?q?J5g/NGCdxT6elFUgAgNZ7T1+Z6Ecz9WhrdfteVT1arWtCmAS0qQ9I1xN8PbV?= =?us-ascii?q?hyG9O+jhDZ2CqqG78Um6aNBJMq7qLWx2LxKNply3bayKkhiEErTdZJNW29ga?= =?us-ascii?q?5/7xPeB4/XnEWFmaamb6Mc3DTC9DTL8W3b9ktVVQdrWvCZBX8YYUTSoJLy4U?= =?us-ascii?q?bqQ7qnE79hMwZdx4iFMKQAIonjgFBPX/y2ZIzRZGW+n2r2DhGN7r+JZZDhPW?= =?us-ascii?q?QQwCubD1ILxURbt3OaHQw5GSqnv3jZFC0oE1/zKQu49PVWrHSkQ0ko1QaSfg?= =?us-ascii?q?tn2qbjqTAPgvnJAdMU2rYJvi0soDYwVG222M7KQZLUvApmeKFRZ9kw61Rvy2?= =?us-ascii?q?/Dthd8MZrmJKdn0A1NOz9rtl/jgk0kQr5LltIn+Ssn?=
X-IPAS-Result: =?us-ascii?q?A2FVAABADgtg/zGZrQpiHQEBAQEJARIBBQUBgXwHAQsBg?= =?us-ascii?q?SJTgSuBOQqENpFYA5pFgUA8CwEBAQEBAQEBAQgBJQoEAQEChEgCF4FjJjUID?= =?us-ascii?q?gIDAQELAQEBBQEBAQEBBgMBAQEChk4Mgjgiez0NPQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCD1RHAQEdAQEBAQMjCkwQAgEIEQQBA?= =?us-ascii?q?QEnAwICAjAUCQgCBAENBQiDH4F+gReyM3aBMopZBoE4AYZ3AYZCQYFCPoERg?= =?us-ascii?q?xk+hFUfgmOCYASBVIIbEIEYGzcBHCoyj2KDJYc1K51QAweCd4kwkjIronSPJ?= =?us-ascii?q?YR5ix6WNQIEAgQFAhaBWAOCDXCDOVAXAg2SEopYdDcCBgoBAQMJinWBEQEB?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) 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.2106.2; Fri, 22 Jan 2021 12:43:28 -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; Fri, 22 Jan 2021 12:43:28 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "bemasc=40google.com@dmarc.ietf.org" <bemasc=40google.com@dmarc.ietf.org>, "mt@lowentropy.net" <mt@lowentropy.net>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] Re: [DNSOP] SVCB without A/AAAA records at the service name
Thread-Index: AQHW63D6+nZnp6DeBEu3WCCDE1fylaosxPoAgAKiM4CAAGUZAIAAEn6AgAAn4YCAACcjgIADxiBQ
Date: Fri, 22 Jan 2021 17:43:28 +0000
Message-ID: <5e619af2c4834afb8ec687e13b8f042e@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>
In-Reply-To: <CAHbrMsD0ZAXX034b952rPM=3M6D2Ea_m373OmJQeOqqkTPvBPg@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_5e619af2c4834afb8ec687e13b8f042everisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OF_Qvo-rE9Qr1Ztxb2B19W3v66c>
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: Fri, 22 Jan 2021 17:43:32 -0000

From: DNSOP <dnsop-bounces@ietf.org> On Behalf Of Ben Schwartz
Sent: Tuesday, January 19, 2021 10:01 PM
To: Martin Thomson <mt@lowentropy.net>
Cc: dnsop <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 a further motivation for the resolver to implement qname minimization with a single resource record type.



   It might be worth reading this blog post to get a better understanding of the impact of another recent source of unintended additional queries to the root servers:



   https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traffic/



   Scott