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

Ben Schwartz <> Wed, 20 January 2021 03:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AA343A0C6F for <>; Tue, 19 Jan 2021 19:00:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.971
X-Spam-Status: No, score=-17.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, 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 tifuCfS6EGxD for <>; Tue, 19 Jan 2021 19:00:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72FFB3A0C3D for <>; Tue, 19 Jan 2021 19:00:49 -0800 (PST)
Received: by with SMTP id y19so44071571iov.2 for <>; Tue, 19 Jan 2021 19:00:49 -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=pMRfJjQeMzyCujQj1yNqWj7CeCNs1i4RmH3kYMKLBbE=; b=bHhoDdTUqbfr7NcBQOZWVGE5SycDdXWUiqCANGF4qUQirb/lTKacrkr3weC27YmFFZ HBzNeM3cIrIhYYW9WFzGkWSgfMpupivJMhBZTkkHG7Ojr4Ura8w+6PWSVCXwIbnHLXD3 0tjSVi8HBIz4zrUDTBn7jUP0PRUhnLxtLGx1KdyUWvXYQsXKKJuByww8qg9fvOY2DZg2 J6freeNmg7SujJNReBPbrS1OvoChPLlT35NWuYD3DAOW7lfArlXKT0UeFBQcwaVm5ujI e7gVXOVHaD5htq/MEUgxXJ1HDGf/DJMWH82rP40l6uH3uc90ElLYGAKzk+NEQmqSFBgQ ss2Q==
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=pMRfJjQeMzyCujQj1yNqWj7CeCNs1i4RmH3kYMKLBbE=; b=HuoKBMUra1uqFEBw5QMqwcOl76tsea6QFTaWCJ+Mn0LLTK2IoDrDMl0GB4xUmr9OAW n/ZH8kqh+x33ZqhSF8K5IgNh92ATvCKCjKS239DUjqPSmFJFJrM6hF+Xqe4ZmuORX4Bo NeLozZPArUQRLcTsUOw+iBf5dzFdkuYyNiIM00RpCA1jQjdkP3Y+WYIgS4Ve8dxbWYkX qvJHj3oIoQAcjaRBnAMYjqf1QmeG/c0y3kV3ggZdnwMZzeKVb6o6SCfshSSVe5BPx4/2 cmaEq01OJI81UPrroelpXxBbylFXI7LM7n/zL1M1p+eXJxNnwqaNOBiXrXOP4GHej8Yk xPTQ==
X-Gm-Message-State: AOAM532nxMn9zG4gwZVlbD9b4RAuCGsNuG0GyWv0pRsHqbqc/dntche/ 37gUlIPWsDbMsZqknwwaf7bKZD8vrPAq1KZp3l9YyavtPYX6nA==
X-Google-Smtp-Source: ABdhPJz+VNacZlRhd0voFo2GisbwOgRf28xEc+FiF7lz9rS6tgnPjl5msYLKetIPgtLMbHVUr7KtQaPTLfMKTnu7Fho=
X-Received: by 2002:a05:6638:d0b:: with SMTP id q11mr5984651jaj.88.1611111646885; Tue, 19 Jan 2021 19:00:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 19 Jan 2021 22:00:35 -0500
Message-ID: <>
To: Martin Thomson <>
Cc: dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000084786405b94c294b"
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: Wed, 20 Jan 2021 03:00:51 -0000

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

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.