Re: [DNSOP] SVCB chain lengths

Patrick McManus <mcmanus@ducksong.com> Mon, 09 December 2019 19:43 UTC

Return-Path: <mcmanus@ducksong.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 370A112012E for <dnsop@ietfa.amsl.com>; Mon, 9 Dec 2019 11:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=RbAslgcf; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=oYyYZdOt
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 HFjtWxQbFiEX for <dnsop@ietfa.amsl.com>; Mon, 9 Dec 2019 11:43:26 -0800 (PST)
Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30D312010F for <dnsop@ietf.org>; Mon, 9 Dec 2019 11:43:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1575920605; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=N4go129ayiNdxYRiBDJfaFOSmzPaPaNLS0L1v1wEbWZWMMTnpEQOmuHiped1OkVlSNYC7SAYOKqwt M56EveG8STbxZCQMlceTulYnaOc6oZFv1Yz1adCcp30NVBP4UQkrbF2p786p/xhe2ptm8+nNBpOmnT SNzQXISQV9iK/mrhkkgkk/pIgplkC/LkRIsIB603KDW0I7VgJ7Yuhem991g1YM6HiKp3//SFpcbkTQ EsCU4KnQcbgGM2ESGMQLWQysHrq9xiRxtiBb3l7zE3ONm4UQbYotdfViXb89f3AQ5c5Yp3Vec48m+f Ap288bIeKg90U9Q7++iZXONhobrFDEw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=8blBVDbID65Y3MucYgapsnHjTfXMwfnFCz+9wr8y2QE=; b=m1vuHF06J4XIFJrboqoJuS6EzOCwEg7nQaWhtR7B3AeZVZO0rOJLAfAj2UXcwmiaTa77+zvPnCdib ZGk7wtxRME97RXYR2nDvdvsD1mOOho8D6LraG2WHzlCfQhiqzNBEGjBvh29EaaBIeLmJsY2Fo7pe9Q /gGRY14d1kuwsWbaXCvQhL+T4z0h2t8kVqHHqSw5xRIgQDJP0y9DO21WWUSuxcD5wRODjCm7YtUFMU hvifb4lnwy3lY7ISQm5PgedarbGer6/ZEug6iksBjBhZ2sWm2kueLKXEqdJtiO2Y1KaewjjhOOHPp5 jAsshfyluGmcwO30NpR2Xj8GqXOpqlQ==
ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.176; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=8blBVDbID65Y3MucYgapsnHjTfXMwfnFCz+9wr8y2QE=; b=RbAslgcfRtJ/szuHbuFf6HO9+mO/BsPySJ7qygu7khKhilCED6+QK14N/shkpqlupZms+06hKpXaQ 1ZM727DpN3NKmN3cWyMiAbhYVnMgfZPOKFzNVEw8UZI8eK2gblv6egRLr/MH43BUQ+NW3cCfwHFV1q 6m6UBs1gESuV1XE8=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=8blBVDbID65Y3MucYgapsnHjTfXMwfnFCz+9wr8y2QE=; b=oYyYZdOt37y3LwrXRjv0jYip+peiZrFwTfEHom5oZVHpp9BLkiE8ryF5sqJsgkSLZzxu2oQ129aP6 YMw7zRlt65EpvMRNGqF1883H16oDLZ7F7LOr5oE1DuoZPGU5kPWwl//4t5/rdRALyhnmsil1rZy4Ii 8sG/JtlnwLzyMyWBVzGnumx8GomvJPsASpY3CFzCgbupsv8p8dVV1Wght+Qqm9+niq4cLYvgZBGdjp 1VDidHC9k1XsEGoU/+khvkqv/GuMPw7ftjhCMcmVP0Qj2dALnYAGkL84Eav4Bd4/f2T8MXRPvtXNdC 3UnKmHBkKKBfppc+uOYd7r0zJOmnZtw==
X-MHO-RoutePath: bWNtYW51cw==
X-MHO-User: 2895f8f9-1abc-11ea-b80c-052b4a66b6b2
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 209.85.167.176
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from mail-oi1-f176.google.com (unknown [209.85.167.176]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 2895f8f9-1abc-11ea-b80c-052b4a66b6b2; Mon, 09 Dec 2019 19:43:23 +0000 (UTC)
Received: by mail-oi1-f176.google.com with SMTP id c16so7490746oic.3 for <dnsop@ietf.org>; Mon, 09 Dec 2019 11:43:22 -0800 (PST)
X-Gm-Message-State: APjAAAXRni4BiVyvTm6x48QSMtrP2MiyURpj1GdjcTY2VOxxzNU9pGcP +1a8Q9NdmfBZsNsdl2WnnIpDtCwBmw0ito9qdlo=
X-Google-Smtp-Source: APXvYqy7kPEtwmYhrGqfv40iM6mE/JPrXletoQ7nY2bknWNLGrIPc0WTbL6nSnuTz0ZUFj/L6Q6/MIQFnN7+FnnwSbk=
X-Received: by 2002:aca:494b:: with SMTP id w72mr753799oia.58.1575920602248; Mon, 09 Dec 2019 11:43:22 -0800 (PST)
MIME-Version: 1.0
References: <CAMOjQcGP3=+_fb9pt3dvF27kR1ENH+=2L28EDNPQU6JF8zkrzQ@mail.gmail.com> <CAH1iCirdFrT_v-FBqaC=WUfaY52DyeYLh5VWbeVsw2YwscDCpA@mail.gmail.com> <CAHbrMsBAmQU-xduT3E4_sHaqrpsdZ_YfdEtgoNB4kti4jDCvdQ@mail.gmail.com>
In-Reply-To: <CAHbrMsBAmQU-xduT3E4_sHaqrpsdZ_YfdEtgoNB4kti4jDCvdQ@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Mon, 9 Dec 2019 14:43:11 -0500
X-Gmail-Original-Message-ID: <CAOdDvNr6Hg2DJYumZ5XY7_yBsKx-+2kiq1tzu9-hRU_u+BgSxg@mail.gmail.com>
Message-ID: <CAOdDvNr6Hg2DJYumZ5XY7_yBsKx-+2kiq1tzu9-hRU_u+BgSxg@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, dnsop <dnsop@ietf.org>, Eric Orth <ericorth=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b0ffa905994a9b9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Bpqdhwx__ejTQJrMUN7md4dNc64>
Subject: Re: [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 19:43:28 -0000

we should not limit the alias chain length across zones (other than for
loop protection which should be standardized) because there is no
administrative consistency across zones - its just a pointer. So the alias
you're pointing at now might become an alias itself later totally out of
your control.. or it might inconsistently do so thanks to
localized/balanced results you don't have any view into. Or, vice-versa,
someone might be pointing an alias at you when you do add an alias record
and you break them suddenly. You can say "don't point at an apex", but the
property of an apex isn't a constant one either - so someone adds a new
apex and breaks everyone that has an alias pointing at them. This is not
centrally coordinated so adding rules that need to be socially tracked
beyond the configuration you actually control is an un-necessarily fragile
system.

I also don't think a value of 1 achieves performance goals because when it
works it just replaces aliases with cnames and they perform the same. Plus,
it creates situations where it doesn't work - and that definitely performs
worse :)

As for use cases, I don't think there is any reason to think an apex wants
fewer redirections than non-apex. We all know that 0 is a real problem, and
that non-apex can have quite a few. redirections are a performance problem,
but substituting cname pointers for alias pointers doesn't improve that.

The loop protection text should indicate that the length of the chain is
inclusive of both kinds of indirections.

-P



On Mon, Dec 9, 2019 at 1:03 PM Ben Schwartz <bemasc=
40google.com@dmarc.ietf.org>; wrote:

> Changed title to reflect this thread's topic.
>
> I wanted to add some background on this question (which is also
> tracked on Github:
> https://github.com/MikeBishop/dns-alt-svc/issues/57).
>
> 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)
>
> --Ben
>
> *For HTTPSSVC (but not SVCB), another difference is that CNAME would
> affect all protocols, whereas AliasForm only affects HTTP connections.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>