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

Ben Schwartz <> Tue, 19 January 2021 22:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D39563A1841 for <>; Tue, 19 Jan 2021 14:18:00 -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 cU58swZBzWZG for <>; Tue, 19 Jan 2021 14:17:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BC233A183F for <>; Tue, 19 Jan 2021 14:17:59 -0800 (PST)
Received: by with SMTP id u17so43005548iow.1 for <>; Tue, 19 Jan 2021 14:17:59 -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=xKFYuKu/vNaqrJ2DLXfSBGnmX42KhGTyv61atCSuKn0=; b=WJ/cKsBzPXB8785JvKSHVRoA9ZyxnY+ZDuquCos+mh4+767ixuipQDejPWf2KkiQ5R V6/d4l8V4GpQOAmIKS/ovxKMc5LfxnWt+96iEGplJ5DkQmgT7jHY21hw+Xf5UuCG8lOA UPf0R5j/k6zH0j4W54+tmiNYFh3j4SKU9NzARbvDFyWx7bf7c00yO3oF6739Pi3hcrNS 4TFg2TWxy7mRdqHGOzC4PcG6Rf1hZOW5TVJgtXXbgjZNKr+QEdJ/nok/lksw1DLVSnTg wlrFHFvk14rALxl8vLWphiKXogmQRzcw+S5t+L4RFfDIfbi12e2TPgRlpxTRwdMXUH7x zRkw==
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=xKFYuKu/vNaqrJ2DLXfSBGnmX42KhGTyv61atCSuKn0=; b=kZUjbKuzarG86Ua604pMyiDhTezk9DIbsjrPTcoymo2BnPg+yEt0LbFdlfN/oOug0O +mRAIdM/Oop38S32Bd+/ribJkrXT41iKL89P6yCFjG7nE3NW6hhK/crdSV+v9rN03Ci9 Jppt5vG1FHM73XSzczIq7YWUrco9udNXyDJcTa842PpvoNks5CJ4vqpveEQDAM6/EHMI Bo/Uy4icNXzikt6v7/s0Djdou8resdugy6YYT0sWec2Ajp1438WjjzIv9klN+grsuEe0 3mJFXqm/tJrJY1lQbmxtxjPWJ3CqWFagFvuIHP19DBSy2zIJWNvGZKY3H+Uc8mMXDsKS C6vw==
X-Gm-Message-State: AOAM5334ZUV0lAghJ38EOYL2goHsfv22Rrqys1EOtuz5sWxefwBfiZ3B +p8GqIjh6M1JyAwuaIPIPNPLxW5sZDBcImDI7Llh/VnT97Y=
X-Google-Smtp-Source: ABdhPJzDqNdmgV2pJylyjQMq8L9vNsgeG951eJQdlWnpkZS1IFjkK8MpQoyUY8LIbBImuqIl4xiThn8weElD5kPT9XE=
X-Received: by 2002:a6b:e805:: with SMTP id f5mr4428962ioh.111.1611094678365; Tue, 19 Jan 2021 14:17:58 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 19 Jan 2021 17:17:47 -0500
Message-ID: <>
To: Martin Thomson <>
Cc: dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000000604d605b94836ba"
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, 19 Jan 2021 22:18:01 -0000

On Tue, Jan 19, 2021 at 4:12 PM Martin Thomson <> wrote:

> On Wed, Jan 20, 2021, at 02:09, Ben Schwartz wrote:
> > I think #288 is quite "specific" about what happens in that case.
> > (Whether it's "sensible" is a separate question.)
> Sorry, I was talking mostly about #299, which has the problem I identified.
> The problem with #288 is that it doesn't say that the A/AAAA queries
> aren't made if they aren't needed.

As I noted in that discussion, the client generally doesn't know in advance
that they aren't needed.  In principle, we could describe two different
kinds of future protocols (one in which clients know they aren't needed,
and one in which they do not), but I think that would just add confusion.
I do expect these A/AAAA records to be useful in the common case for future

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: [...]}.  If the hostIPs aren't useful
for this protocol, the app can ignore them, while still getting the latency
benefit if any of the svcbEntries rely on them.