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

Ben Schwartz <bemasc@google.com> Tue, 26 January 2021 19:59 UTC

Return-Path: <bemasc@google.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 D0CDE3A0E13 for <dnsop@ietfa.amsl.com>; Tue, 26 Jan 2021 11:59:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.699
X-Spam-Level:
X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 9X-7o9vf7Pnc for <dnsop@ietfa.amsl.com>; Tue, 26 Jan 2021 11:59:39 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2373A0E12 for <dnsop@ietf.org>; Tue, 26 Jan 2021 11:59:39 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id z22so36169672ioh.9 for <dnsop@ietf.org>; Tue, 26 Jan 2021 11:59:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z0SG6XsT3ZN+4Dsd2u5WywU7F2Aqxo4fzLVmUt5Gfso=; b=AsX1CZR07G838L6BYCvt1pe3pQgW/4VRcfIJ+t+kQKLBh4HW7XbmOtOAD1e5vURIje V9wofXqqKMNl7AevQY9JKTMLx/uFDq/OE5h4RA6kfLkeGsWsp922iSlNDqT+p3mgOway uzGghQ+6/AxBw9ACgnmgNZB0I5nXKrlXSwbYzhuiubI2rmKErxya9kITAMVbhkNqYoLE 7O84m9zEeBhSxKoamlIQMt942D+bSE2Dv+QTTKELolTb/s7lfecdFPuU0pVqVppzyZjd 507FPaFN3FtRsKNt/6p5LYC8gTmZlTjSvHMb9nrw4AgFyrEU9hAy5BJQWV/jk8RG960V ZJYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z0SG6XsT3ZN+4Dsd2u5WywU7F2Aqxo4fzLVmUt5Gfso=; b=rT1S2POMj1Xf4Hpx9eDQ3ovM3Dfa2aTcMOHCyzChpzve3lzUobH/jhthkbWlCvJlqf 1XwzyZKi1rz9q8Vqo01fj0ODwJWdry8Jk3EwUTJl1FK7xuHCbPeWHluY9tumNWXd4A4a N+FFQZ0TP7qmEcDiBHz+YU6d8K3GBtTKk9dlmgQgNAfyyMJHzr/5Tcb0m45QSF9dZZBk dptgA1RA9h8IGIr3sTAYpDOP9gfM6c1sUM/fcC0jXdXjDp5loSsAy3Tb8V/1yCpbht84 XPnKJuJcIxfK9y3bKZiflLxmwovIN5S/IPZg5VHYazSGcw20gBwEgHftWUUIGWXciEP8 3Zdg==
X-Gm-Message-State: AOAM533RkQlriwo7hKKkLf2+x585Ika9XDQ9eesefjX2vALLl+F1AxXc 1pUZXponliyu0o7LI9op2FIbFrM0XFy6p1Xaf592ueWeXJo=
X-Google-Smtp-Source: ABdhPJwzIgZEssyJdD5mMH7pBy4ezc7kt4kEEb1NdiX3lNUt5TiBXvmLq2nkLAE7Bde2YfGu3BT9yEiTpN+mtF+srp0=
X-Received: by 2002:a6b:c8d2:: with SMTP id y201mr5226723iof.134.1611691178493; Tue, 26 Jan 2021 11:59:38 -0800 (PST)
MIME-Version: 1.0
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>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 26 Jan 2021 14:59:27 -0500
Message-ID: <CAHbrMsAEMjSPYSe4Eg_LjaqhLvBkg-caQ9joLYUERAYHqMxrBA@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000035472105b9d318ab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2aXU0TmgoSTMYDa9nPnZxLl_Ih4>
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: Tue, 26 Jan 2021 19:59:42 -0000

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.
>