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

Ben Schwartz <bemasc@google.com> Fri, 22 January 2021 18:29 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 3E2AF3A13D9 for <dnsop@ietfa.amsl.com>; Fri, 22 Jan 2021 10:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.971
X-Spam-Level:
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: 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 WzeG4fpd5VJI for <dnsop@ietfa.amsl.com>; Fri, 22 Jan 2021 10:29:30 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 416303A13DE for <dnsop@ietf.org>; Fri, 22 Jan 2021 10:29:30 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id e22so13096683iom.5 for <dnsop@ietf.org>; Fri, 22 Jan 2021 10:29:30 -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=Yq63C/IjQS2HfwnekXYKpckWJ77HpWuFRBlvPvd8CKU=; b=MY9cRmmeq2CHLJo6fz9WWasigLu/UL3aUO5v4x6VhaOJtc6kv4XcAOxZddpusHH9EF U8R7A1xXU/j2WSO6M8+ygj4oTdBz3p2CQuBVX2vIuvZRhM43QNESdM629lW821wi3eNa lNPvVwTEKdwgjnnvv5guYZBU+LUHW+4Ox1v/A6qfZMJ06Lx+I0X1JgYxsWIttqePWT/c jEHEYI6w7vr6axBw4FueWTi+o8/gZRRNiN+TYM767Gpcu2iW6FjFoBJ77ptB2UkarXNb dLUtEAlu5kIuDWc4VarXYuvUfbhNmF9/ZJMg8cXNd9ARvUA9kHfZRe2ioD1Cdb67LR4M 94Jw==
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=Yq63C/IjQS2HfwnekXYKpckWJ77HpWuFRBlvPvd8CKU=; b=W9tSSMGDghrW6kt74GXhih9aSq9VBDjLFJkxK3zbRSiSKWcIaxQeeHUM6SnKPlCT34 N1upXrXgKN5p4W5fu7eBt2UeO1M1EQyp2kJCkN26oPv6xeSTWMt2GMO3oAnfC/uqW3Mg kAP4RTlWIIfvYpWf5QSyqTHQdttKCGXp57OLdlnuiLabefDeUSXQAsBQLog0bJpZUw0v 2wYAAB8iCbeaSIobRGyPJ3L/BKE2wPNPIuQuGwEbot9fABMT2HSH0erPRfq8luQxsH8c iDfA/zYIh2b6RNoLyg82LA/KyjayKT2va0VPDUpmXSE3r6uQxaIVkn+4caltSqNppij1 pzuA==
X-Gm-Message-State: AOAM5320Eyrvc9QNkUgomgwf+E+1Uv6Ja4TRRYZtA1Bx94TqROuyWTki +XDxhSBljerpabDdVQb23ibJAz6EcjczMgHyfeIowrWJ5Ts=
X-Google-Smtp-Source: ABdhPJxM/xIFB9nNoWpaIf4uQ9aMu0zz7wKZXTkcgQE7BMhm2fjRuUsOHQJ9fAHh/v8uo2XAb4X7YRJXQNlZ8jiT354=
X-Received: by 2002:a92:5b8e:: with SMTP id c14mr5267228ilg.275.1611340168371; Fri, 22 Jan 2021 10:29:28 -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> <5e619af2c4834afb8ec687e13b8f042e@verisign.com>
In-Reply-To: <5e619af2c4834afb8ec687e13b8f042e@verisign.com>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 22 Jan 2021 13:29:17 -0500
Message-ID: <CAHbrMsCaCOrqXqBYx3iEbXsSXSJFdiHWw+pDNz7YS_Ahb_-UyA@mail.gmail.com>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
Cc: "mt@lowentropy.net" <mt@lowentropy.net>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000005e6ad605b9815e61"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WGfbK2M0_ClMLvxexJ6zhLdnh_c>
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: Fri, 22 Jan 2021 18:29:33 -0000

On Fri, Jan 22, 2021 at 12:43 PM Hollenbeck, Scott <shollenbeck=
40verisign.com@dmarc.ietf.org> wrote:

> *From:* DNSOP <dnsop-bounces@ietf.org> *On Behalf Of * Ben Schwartz
> *Sent:* Tuesday, January 19, 2021 10:01 PM
> *To:* Martin Thomson <mt@lowentropy.net>
> *Cc:* dnsop <dnsop@ietf.org>
> *Subject:* [EXTERNAL] Re: [DNSOP] SVCB without A/AAAA records at the
> service name
>
>
>
>
>
>
>
> 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.
>
>
>
>
> *[SAH] We need to think about the impact on the servers that have to
> respond to those queries, too. Sending unnecessary queries to the root and
> TLD servers puts a load on those servers that can have an impact on every
> client/resolver that needs to be able to reach them.*
>

This is important, but I don't think it's applicable here.  The various
options under consideration all impose the same amount of load on root and
TLD servers.