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

Martin Thomson <mt@lowentropy.net> Wed, 27 January 2021 00:35 UTC

Return-Path: <mt@lowentropy.net>
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 5C1983A0E4B for <dnsop@ietfa.amsl.com>; Tue, 26 Jan 2021 16:35:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_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=lowentropy.net header.b=A7IcICth; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=apg4iJil
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 NFd8tCUXpaBh for <dnsop@ietfa.amsl.com>; Tue, 26 Jan 2021 16:35:37 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2603A0E4A for <dnsop@ietf.org>; Tue, 26 Jan 2021 16:35:37 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 5ECB2B24; Tue, 26 Jan 2021 19:35:36 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 26 Jan 2021 19:35:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=sPioIeeM9PVv+nsxcUEysa+O2doD KIFdvrO/Cu8QrT8=; b=A7IcICth75IMDoiK+mCDN0J876g5EtoT+te3oc7d//fA +8Ve46FUytXG20mrZpPR6ADPNthR1IY+C2Wr9V+zZT/QFgm7rUO11eZ6/bzZkmNA CyuiTNLfiSNSmXnVxNL3kATyfOd/HVHDGTTej+340RpZIEV1eGWvwbl/t7YyRqNo sqCX2Cjlb91QQQu4RhZubDtrnA1ooto81YANBXj1dIRRFjPtIOrGrvmLrzr1zkZw glvSDNXPKjzDUlynTTyWN8wd/L3IsVhAtoGzfEhM9aiIDEyiEPNFH1+6BCOVl1zF 7cI4+iRWobFKNiFTEgndXbgLRAhy3utNbvzUh6i74Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=sPioIe eM9PVv+nsxcUEysa+O2doDKIFdvrO/Cu8QrT8=; b=apg4iJilXhu0BLD6h6j5hL rmgDalHzLDwmCxUkY7SsvwkTv9v8eIkRd8xGo9wJ0kVOkbGNd9cE6vl6DQ/EaIRb 5JumvsdIQ8yDdtz0HT70v5KyAUsap2GbNDhXb5v3flB3e1B1IvYdxuvQPFfRTJXP 9wHrKb7cOnQKYSYIOkEjhbsZ9xYHucoxdSfSIacglcs6ycHZUbWFXsk4aFBRcMgs +PRP//Q+lg8XPMo97FPWZsUUKuug1wHdhNYxL3SJZmReBktx2R9zJDKYS1aCbIxg MRMwbJ3oh8CadS8iRhzle6a0JGWTmwSOcPEvCRwhGHavk5M3MR4JcWcnh8s8UI8Q ==
X-ME-Sender: <xms:V7UQYAVHDowDSvK3IemVtzbVGnptWVOLwkdu1b0-moemBLtn_tDn-g> <xme:V7UQYEnXdIwtgE2nbKMazM3-x3zw9ErWutHbD31visUKjeDR72U0acEa8sXT5Ga1C f9w6ayCUAgjDDiFakc>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepvdeuhfefteefvedtteelge dtkefgieeuieeuffdthefgffehffetueelvdehfedunecuffhomhgrihhnpehhthhtphhs ihhsnhhothhsvhgtsgdqrhgvlhhirghnthdrihhnpdhgohhoghhlvgdrtghomhenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigv nhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:V7UQYEaY14N85-Q3CgqsrbkWthScDWYZ65hsBoyjtFMYVoXWxeYcWg> <xmx:V7UQYPUlBi9bWTdvuf7VON4Gzu8NIFIRGSsYDbl_Yr6te4wJBzXvVw> <xmx:V7UQYKkL2DvbM56UNTbI3MGRu06ojwCyvamvDqQqBx6RfQuUJd4WEQ> <xmx:WLUQYERKF5EIfcBIDz20kBh4ZGptvB5xtUOQcLM5-wsbj-aizQRrwg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B1C604E0062; Tue, 26 Jan 2021 19:35:35 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-84-gfc141fe8b8-fm-20210125.001-gfc141fe8
Mime-Version: 1.0
Message-Id: <49abbb79-d465-48f9-8d39-446abed2ba96@www.fastmail.com>
In-Reply-To: <CAHbrMsAEMjSPYSe4Eg_LjaqhLvBkg-caQ9joLYUERAYHqMxrBA@mail.gmail.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> <CAHbrMsAEMjSPYSe4Eg_LjaqhLvBkg-caQ9joLYUERAYHqMxrBA@mail.gmail.com>
Date: Wed, 27 Jan 2021 11:35:18 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: "Ben Schwartz" <bemasc@google.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6jyvHWQd6VYLeIZrZvSmiHJeooY>
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: Wed, 27 Jan 2021 00:35:39 -0000

My apologies here, I think that I misunderstood the structure of the proposed algorithm originally, however, that might be an opportunity to improve the description.

My conclusion here is not the same as yours.  If you require SVCB, you might need a different algorithm, or at a minimum you need to run the math (as you have) for whether you will get a TargetName and whether the TargetName will be "." before considering the optimizations you are promoting.

If you use HTTPS as the example, the algorithm, as described, is completely reasonable.  But HTTPS is weird.  If you are looking at a new protocol deployment, other factors, such as compatibility with HTTPS deployments, might change those numbers considerably.  That is, P_svcb in this alternative setting is 1.  If we were to do this for a protocol that was allergic to HTTPS - SMTP is probably a bad example because MX exists, but imagine a similar deployment arrangement - the result might be that the probability of there being a TargetName in the record is closer to 0 due to the prevalence of outsourcing of serving.  At that point, you might decide not to spend the cycles on A/AAAA queries.

HTTPS is also weird in the sense that it is so aggressively latency sensitive.  Even if P_targethost was extraordinarily low (maybe not 1%, but we've wasted cycles on gains with far worse odds), we'd still probably spend the effort on it.

So I think that you have this entirely backwards.   The concurrent querying of SVCB and A/AAAA is some combination of an optimization and unique to the one worked example we have.  Acknowledging that might allow the draft to be much clearer about the logical structure of the process clients follow AND make it clearer where the optimization opportunities are and how clients might reasonably decide to take advantage of them.  Then you can explain how different deployment choices (such TargetName == ".") might further take advantage of those optimizations.

As it is, the algorithm is presented as being definitive, but it really isn't.  What you have is the optimized version of the algorithm, with no real acknowledgment that alternatives might exist.

--Martin




On Wed, Jan 27, 2021, at 06:59, Ben Schwartz wrote:
> I'd like to try to get to consensus on this point, which is one of the 
> last open issues for the draft.
> 
> To restate my previous argument, let P_svcb be the probability that a 
> SVCB record is present, and if so, let P_targethost be the probability 
> that it contains a TargetName that is the hostname.  Then (ignoring 
> Additional Section processing) the initial AAAA/A query saves (1 - 
> P_svcb) + P_svcb*P_targethost resolver roundtrips, on average.  
> 
> Currently, for HTTPS, P_svcb is about 15%(!), and P_targethost is 
> ~100%*, so this always saves one resolver roundtrip.
> 
> For a SVCB-reliant protocol, P_svcb is 100%, so the formula simplifies 
> to "P_targethost".  If P_svcb for HTTPS were to approach 100%, the 
> result would be the same, even though HTTPS is not SVCB-reliant.
> 
> In other words, keeping P_targethost high, and using speculative 
> queries, is good for performance when SVCB is heavily used.
> 
> * Assuming Cloudflare has the only current large-scale deployment of 
> HTTPS records.
> 
> On Tue, Jan 19, 2021 at 10:00 PM Ben Schwartz <bemasc@google.com> wrote:
> > 
> > 
> > On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson <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.
> > 
> > Section 10.2 ("Structuring zones for performance") takes this observation and turns it into a recommended convention for the use of TargetName.  You can place TargetName anywhere, but if you can line it up with the hostname you'll get better performance, so that's recommended.
> > 
> > If I were arguing for your version, I would say either:
> > 1. By the time we have SVCB-reliant protocols, nearly all resolvers will have implemented Additional Section processing, so the client won't have to issue A/AAAA queries at all.
> > OR 2. There will be SVCB-reliant protocols where it is normally inconvenient to use A/AAAA records on the hostname, so the client knows that the TargetName->hostname convention doesn't apply.
> > 
> > Personally, I don't believe either of those things ... and since they're both predictions about future standards, we can always clarify in the future.
> > 
> > It's worth noting that the sentence in question (Section 3 point 2) has no normative force.  That section is just describing what clients are expected to do.  So if you want to do it differently ... whatever works.
> > 
> >> > Another thing I like about the arrangement in #288 is that it 
> >> > simplifies a protocol-independent app/library boundary.  The app can 
> >> > say "SVCBQuery(hostname, prefixes)" and get back a fully resolved 
> >> > object like {svcbEntries: [{...}, ...], hostIPs: [...]}.  
> >> 
> >> I'm suggesting that the interface might be a little wider.
> > 
> > Sure, that's fine too.
> >  
> > ...
> >> svcb.query_with_fallback(name) -> Either<svcbEntry[], address[]>
> > 
> > Nit: Pair<svcbEntry[], address[]>.  If the svcbEntries are all unreachable, clients SHOULD fall back to bare IPs. 
> Attachments:
> * smime.p7s