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

Ben Schwartz <bemasc@google.com> Mon, 25 January 2021 22:04 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 0B3433A198B for <dnsop@ietfa.amsl.com>; Mon, 25 Jan 2021 14:04:16 -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 3Ob_FeNVk7sj for <dnsop@ietfa.amsl.com>; Mon, 25 Jan 2021 14:04:14 -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 7443A3A1987 for <dnsop@ietf.org>; Mon, 25 Jan 2021 14:04:14 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id x21so29808846iog.10 for <dnsop@ietf.org>; Mon, 25 Jan 2021 14:04:14 -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=vGXV95HsD/QdaW0R5Fz8Aahuprs3wY8scnhJf4+8DWo=; b=boIlQ6FSNSjtxqz8neLjb646K6pRJ49eOb7cjnDx2x71lz46+0sFQOocs8z79zcapx Mhysid2n8bfqDEwRVpnN6lsTVsMuZkKCQklYX5PJGNJPANWVvhb2PBGKqFwF86ZRFO77 aTX1pwi5U+NPMtJl2RqgAor8+/IDcakOmG4ezVuq0OgTVRapckWarpAu72aQoTTjj1eo g/yILb2vZwtQ8nvSC34wPXJ9Tl20cxtxKDR0jGg41OF/Z9IHD6+my32yVa3WHut0tpM3 lJNno3Psg6GqF8cr8sqEfuDTT0wCVlBCFVEkdl6OHzeuaF7Hq2YAbSw1K4GEoQ/qye8e kkhg==
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=vGXV95HsD/QdaW0R5Fz8Aahuprs3wY8scnhJf4+8DWo=; b=gbg7890tOUVLUpJEOMC8iWQjJB0Xbkq32WGdeQzbSNSu7nshWU9Qk+LrNUDhX5Pqpz OXhPUZPQcNbdxCN6y1REVKpozdlOuth7+6rQz0zBV2v2Lnj1gCwYSNXyFgGXtZ5MKIBS MPGbcrDSclSb2PTCRimAz6YrGc/sFqBcTocqj2ToqTNOfzaGY0mAg1Cujo56KBxWVc5T f3RIp+CwXaHl5cKI8IQ8Up3NwcN3SiNT5T0sc0T3iAVAtLPcke56O617x97dg0+Dg859 3V0xltKhqP4Bf0210aXTXgjRxochUx/m/adkxUXmy8V9rWxAih736jzJrt+kUwbE5Fzm f0QA==
X-Gm-Message-State: AOAM5311RoBNBJgm3MAIYgRCh3KS7A5kx83lca5InWp6y31kY9dwnaJm 49OsKpVq3qSqczAf1+Cq+rGDSeDcUAEYXnr9gp5ivw==
X-Google-Smtp-Source: ABdhPJzlbVCns7XAKaaS/OgrfbNv5/Y1ayNe5wOi7jLNs+8Sw9wuDtCfYauHAqVEFiwBCPKLKF/4fAt76ExfFeMo8HA=
X-Received: by 2002:a05:6638:3012:: with SMTP id r18mr2395388jak.13.1611612253144; Mon, 25 Jan 2021 14:04:13 -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> <CAHbrMsCaCOrqXqBYx3iEbXsSXSJFdiHWw+pDNz7YS_Ahb_-UyA@mail.gmail.com> <3e819f32679c403489b4b01968159acf@verisign.com>
In-Reply-To: <3e819f32679c403489b4b01968159acf@verisign.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 25 Jan 2021 17:04:01 -0500
Message-ID: <CAHbrMsAt1usc0MFAgL+p7bLb2e3nScyMyoy35T1NAWaumEH_RQ@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="000000000000e60d8b05b9c0b772"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mvVK080i0FeKTcCHpg01fxbosxY>
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: Mon, 25 Jan 2021 22:04:16 -0000

On Mon, Jan 25, 2021 at 8:06 AM Hollenbeck, Scott <shollenbeck=
40verisign.com@dmarc.ietf.org> wrote:

> *[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.
>
>
> *[SAH] So if some number if queries X and some number of queries Y are
> processed in parallel, the value of X + Y will be the same as if those
> queries are processed serially?*
>

Yes, if the SVCB record uses the hostname as the TargetName, as suggested
in section 10.2, then there are no additional queries; they are merely
issued in parallel rather than sequentially.

Regardless of whether the speculative queries are wasted, your question was
whether they would impose more load on TLD or root servers.  If the
domain's NS record is cached at the resolver, then they certainly will
not.  (All queries will go to the authoritative nameserver.)  If QNAME
minimization is applied, they also should not.  (They will all trigger the
same qname-minimized query to the root and TLD, and a reasonably
intelligent resolver shouldn't emit duplicate queries when one is already
in flight.)

If the NS record is not cached, and the resolver does not implement qname
minimization, then perhaps it is possible that the additional queries could
leak to the TLD, or to the root if the TLD NS record is not cached.  The
behavior would be similar to speculative AAAA queries today.  (I'm not
aware of these being a cause for alarm among root or TLD operators.)

Note that this conversation only concerns hypothetical future non-HTTP
protocols that rely exclusively on SVCB.  We are a very long way from any
such protocol (1) existing and (2) having enough usage to concern the root
or TLD operators.