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

Ben Schwartz <> Tue, 26 January 2021 19:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0CDE3A0E13 for <>; Tue, 26 Jan 2021 11:59:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9X-7o9vf7Pnc for <>; Tue, 26 Jan 2021 11:59:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C2373A0E12 for <>; Tue, 26 Jan 2021 11:59:39 -0800 (PST)
Received: by with SMTP id z22so36169672ioh.9 for <>; Tue, 26 Jan 2021 11:59:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 26 Jan 2021 14:59:27 -0500
Message-ID: <>
To: Martin Thomson <>
Cc: dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000035472105b9d318ab"
Archived-At: <>
Subject: Re: [DNSOP] SVCB without A/AAAA records at the service name
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

On Tue, Jan 19, 2021 at 10:00 PM Ben Schwartz <> wrote:

> On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson <> 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.