[DNSOP] SVCB chain lengths

Ben Schwartz <bemasc@google.com> Mon, 09 December 2019 18:03 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3058912004F for <dnsop@ietfa.amsl.com>; Mon, 9 Dec 2019 10:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.401
X-Spam-Status: No, score=-17.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, MIME_BOUND_DIGITS_15=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RpDNxw-0wjaS for <dnsop@ietfa.amsl.com>; Mon, 9 Dec 2019 10:03:48 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 63E5C120121 for <dnsop@ietf.org>; Mon, 9 Dec 2019 10:03:48 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id f82so15736127ioa.9 for <dnsop@ietf.org>; Mon, 09 Dec 2019 10:03:48 -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=LNzaWNf27/MgzVrG4AD2lSiLWTpWMqxVRVKqCCyWgb4=; b=L5sFFv6ySdr8wePRCMKoiIao1Fo2jjoGgEu8TUIMkD8F8WP8GwTN5GtKYavNuX0KY3 obTk8speYzvSRpLF41qiwoFelP4aMWrBfVe+FI8mwrmECCEVpjg989+8ZXr4/xpf6lO7 U8ZLC4Xc89Y0PRGvcJMNLCSPNk2eNI64GNhDsGv4/HgM5nCKqz/aNN9H+Z4QwyRDy2dZ AAujiXcmuL/+nlK32/wd8oKvsuJLg8wWB0+BaULuYq6D9WnWPEeVA4y1nCJJUkMcVMdO XuFF8fuHqz/WGgw5Lz8sfb5HrLYfWOXxTP21FpK6GnfwmZGr2Ifz8QunMC++rlHGAUzh R+4g==
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=LNzaWNf27/MgzVrG4AD2lSiLWTpWMqxVRVKqCCyWgb4=; b=ASJYEloSm94Cm751HJeWUcZD15LzNlTpwGCkLWkuh1Pv3i92xzdnqyX1uH15dzXYzc GQDDfYHoA3gtywBQjp1VlXImnd0wC05B9dIdN1qRfURcEQ4DL9hir4JPWcs0JNC48EdH suqkCFW+ZbqhVUg31Sn8inBidO5UTIsE/m8cMaTa2Pin095r+1sNTcRJDOW1evvergfR EY2xSoUXoiqHY3lCKNpU8N3BJc0fFuR6xguQJLVL2bR/Y4lBQ4jSOQ1WvEhqNVysysAj IIvER/ZXfw47X3wEOcY4VnW2GOwiYuRGCdzylKX2a/3kR6qnYE39N153T8E9lE0ZYKoz T+4A==
X-Gm-Message-State: APjAAAWzgCY4UX6n/2EhmxGkCkswo9a81Z2KRHA8bmWo24u4mN1zeMy2 CHTZY+BoU1JUr0ZV4prcz2ijrdN+sjbIIeOAn7NwFA==
X-Google-Smtp-Source: APXvYqzxHrKcmuCxhcK9UQByJ2Wdu/NVAQ5bbhP62DJ64PmM7HVwIishVN95euvVe1wVmKTPtdNwgZeP0h09kvXCDsM=
X-Received: by 2002:a02:c942:: with SMTP id u2mr11518837jao.49.1575914627323; Mon, 09 Dec 2019 10:03:47 -0800 (PST)
MIME-Version: 1.0
References: <CAMOjQcGP3=+_fb9pt3dvF27kR1ENH+=2L28EDNPQU6JF8zkrzQ@mail.gmail.com> <CAH1iCirdFrT_v-FBqaC=WUfaY52DyeYLh5VWbeVsw2YwscDCpA@mail.gmail.com>
In-Reply-To: <CAH1iCirdFrT_v-FBqaC=WUfaY52DyeYLh5VWbeVsw2YwscDCpA@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 9 Dec 2019 13:03:35 -0500
Message-ID: <CAHbrMsBAmQU-xduT3E4_sHaqrpsdZ_YfdEtgoNB4kti4jDCvdQ@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Eric Orth <ericorth=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000009837460599493753"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Fim9mbPIfSBwBQg-3uU6wwSfmhg>
Subject: [DNSOP] SVCB chain lengths
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, 09 Dec 2019 18:03:50 -0000

Changed title to reflect this thread's topic.

I wanted to add some background on this question (which is also
tracked on Github:

SVCB supports two forms, one of which ("AliasForm") acts somewhat like
a CNAME, and in principle could be chained indefinitely.  The current
draft says

> Chains of consecutive SVCB and CNAME records SHOULD be limited to (8?) prior to reaching terminal address records.

This discussion is about finding a good replacement for this
placeholder language.  (IMHO the placeholder is also problematic
because it arguably alters requirements for CNAME handling.)

SVCB is fully "mixable" with CNAME, so there's no need to use SVCB's
AliasForm when CNAME will do.  CNAME chains are followed at every step
of SVCB resolution.  AliasForm's only significant* advantage is that
it can be used at a zone apex.

AliasForm also has a serious downside compared to CNAME: clients whose
recursive resolver is not SVCB-aware will have to follow the alias
themselves, resulting in significantly slower resolution than a CNAME.
For this reason, domain owners should avoid using AliasForm if CNAME
will suffice.

If zone owners are testing/benchmarking with recursive resolvers that
are SVCB-aware or have very low latency (as seems likely), they may
not expect this penalty, and there is no way for them to detect or
measure it after deployment.  I have heard this called a "performance
footgun".  Hopefully this explains why some developers have asked to
limit the use of AliasForm.

Currently (pre-SVCB), the number of apex names that can be present in
a chain is zero (excluding the final name).  The question at hand is:
should we increase this limit to 1? 2? 8? Unspecified?  We have a
clear use case for 1 (aliasing https://example.com/), but I have yet
to hear of a use case that needs a limit higher than 1.

There are also several other possible ways to discourage unnecessary
uses of AliasForm.  For example, we could:
 - make it possible for zone owners to tell whether their clients are
using an SVCB-aware recursive, by making clients' alias chasing
behavior different from recursives'
 - extend the W3C Resource Timing API (at the W3C) to indicate when
multiple DNS queries were required
 - ask SVCB-aware recursives to SERVFAIL on AliasForm records that are
not at an apex (excluding _prefixed labels)


*For HTTPSSVC (but not SVCB), another difference is that CNAME would
affect all protocols, whereas AliasForm only affects HTTP connections.