Re: [DNSOP] SVCB chain lengths

Eric Orth <ericorth@google.com> Fri, 27 December 2019 18:25 UTC

Return-Path: <ericorth@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 059F512013B for <dnsop@ietfa.amsl.com>; Fri, 27 Dec 2019 10:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 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, HTML_MESSAGE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI2HYFuns9fM for <dnsop@ietfa.amsl.com>; Fri, 27 Dec 2019 10:25:43 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 ECEAA120018 for <dnsop@ietf.org>; Fri, 27 Dec 2019 10:25:42 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id f129so8887083wmf.2 for <dnsop@ietf.org>; Fri, 27 Dec 2019 10:25:42 -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; bh=HprcfePfXT7krV5l5WNd0rUfnUm14HEdDWpzSC72c48=; b=Kubkhospg56JGJ94bSczOCbNdAsLcyYb8aRVSkpS9d7tnJtdZVx37wO1hPhfQ9z59/ ZzEANg5Ij2XVaInW6wYKUJTSD+1609J1GRJDe6Z+JdY3TwgpRJs7k0TNU3Io/E0WCV0m +umG/o9Nn7tEATyAnc++avYUzQcLYEJB0FWBlkkyIr7URauVuQkwDEHct1MjrdJzBnDq 0Di/8o34XGPwRdF14r2qUsrHZ0+Wx01FOaWS/CLbOH6H9t+O5JWUDIN6+FkYiCOaTQXk q5nFlS9orU3rUNMY+AOrnTosa46/vXhqxq8WSPwse6UiHcThsWnNlMBHrJ2M33uO/Rxe fFtQ==
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; bh=HprcfePfXT7krV5l5WNd0rUfnUm14HEdDWpzSC72c48=; b=ggR3MxptY9geLeZgvgE1BG/JqxCqLvVfeCedfFgI+3wp+mJj8VmG5cEWC1vgmA0A72 IhZaQxvsboIWZbA1My8DNPlvi9CmXqPATP0lDZOHmOQfW1+u/8z9HofSIF+L711tcBtX +wYFaNZLWkE+If8ZIFXT1vSUuXkAyo3h3/vDfqt2z3fZynP1VfFDRFK4V0KBC2nG2vdc q03UcJ4JhmKF9dwK4b2WKRr3dVVAuWdbhWRAHOue1us9iv6IANJKSqjzvyN8vm+wUhVw 9dayKXRddv56Td4tNIHN7WgMbdUBxnvHBOFgMjKpEjeNxI1gGUxmXdUvYYeFp0wTONW8 2B7Q==
X-Gm-Message-State: APjAAAXixFKr2t9zulm7p62GT1S2Zt5XCdCzcKRj0hYKjTLeluTyg7WM jMWj1M5rKHhiKyYNhvDmikFeK65vN792iXGM+yxtHbgpgBs=
X-Google-Smtp-Source: APXvYqxnJJH9CefE8s2P44rmtsbE/z1VDjt1mAPYj26Bu2WJvRTuKOonZvv7vyC59Gh0zH8tYMVswNC1nRE8Dswnx0A=
X-Received: by 2002:a1c:3dd5:: with SMTP id k204mr19915061wma.92.1577471140821; Fri, 27 Dec 2019 10:25:40 -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> <CAH1iCip0iY8Mt8=HC0-V8jF=D=BGcs54xUMu4Rkbe47FFxGyuA@mail.gmail.com> <CAMOjQcG2YOBa1X7ZqAUpDG0Cwr+nOzmy-bKJmbqaQEqrcTOCAQ@mail.gmail.com> <CAH1iCip6CdLSNAmBB-j=Qya26j=OoLoBGyMtXEWQ0sQz9Z2HYw@mail.gmail.com> <CAMOjQcGLhu-27932_FoyNmV=7RGG074zzkaGNxHMs0qrfAO+4A@mail.gmail.com>
In-Reply-To: <CAMOjQcGLhu-27932_FoyNmV=7RGG074zzkaGNxHMs0qrfAO+4A@mail.gmail.com>
From: Eric Orth <ericorth@google.com>
Date: Fri, 27 Dec 2019 13:25:29 -0500
Message-ID: <CAMOjQcEZqvpYNTJ7vRXdkC11mUYADvBOnzOHTwWH49wyXBfp_Q@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fe73bd059ab39ebc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LeRqbpfrPHbCIcCgt3KLHcFqm3g>
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: Fri, 27 Dec 2019 18:25:46 -0000

I propose we add the following 4 statements to the spec:
1) Alias-form SVCB records SHOULD NOT delegate to names with any form of
alias record such as alias-form SVCB or CNAME.
2) Clients receiving SVCB records MAY limit the length of chains of
alias-form SVCB records that they will follow.
3) Stub resolvers SHOULD follow at least one alias-form HTTPSSVC record
before enforcing chain limits.
4) Recursive resolvers SHOULD follow at least (8?) alias-form
HTTPSSVC records before enforcing chain limits.

Point (1) is an extension/clarification of the similar rule for CNAME in
RFC1034.  I think SVCB would work a lot better if everybody just always
aliases to the final server whenever possible and reasonable.

Point (2) essentially serves as a warning to not assume long chains will
always be followed.  The allowed length may vary, but many operators are
going to impose a limit at some point out of practicality.

Points (3) and (4) set the expectation of reasonable minimum limits for
everything to work well.  Recursives are given a higher limit because, as
stated in this thread, it is very reasonable for those operators to support
such higher limits.  Stubs are given a lower limit because it is less
reasonable for them to support the long chains, but they are still expected
to follow at least one alias because that is the minimum to support the
obvious usecase of allowing https://example.com/ aliasing.  Both these
points only apply to HTTPSSVC, and leave SVCB less defined, as what is
reasonable behavior may be more varied in non-HTTPS cases.

On Fri, Dec 27, 2019 at 12:54 PM Eric Orth <ericorth@google.com> wrote:

>
>
> On Mon, Dec 23, 2019 at 3:57 PM Brian Dickson <
> brian.peter.dickson@gmail.com> wrote:
>
>>
>>
>>> Being typically further away from results and with less caching,
>>> unlimited chain following just does not seem reasonable for a stub like
>>> Chrome, and it seems to us to have a big potential to be detrimental to our
>>> users' experiences compared to the status quo of not following any chains.
>>>
>>
>> This puts the necessary and appropriate pressure on stub clients to their
>> resolver operators, to deploy Alias-form aware resolvers.
>>
>> Putting in place (IMHO) hacks, to reduce or eliminate that "pain",
>> removes ANY incentive for resolver operators to actually deploy this stuff.
>>
>> If resolver operators NEVER deploy this stuff, we may as well chuck it
>> before we adopt this, since there will be literally zero benefit, while
>> creating non-trivial amounts of cost (in terms of stub client
>> implementations, authority-server implementations, zone owner deployments,
>> etc.)
>>
>> BTW, I'm strongly in favor of this getting adopted, and getting deployed
>> in recursive resolvers.
>>
>> Thus, I'm in favor of NOT having alias-form limits, even on the stubs.
>> This will lead to much faster adoption, compared to "Real Soon Now", "Some
>> Day", "Eventually", and "We Never Promised To Do That".
>> (The latter set of responses paraphrased from an un-named registrar who
>> eventually reneged on "promises" to deploy DNSSEC support.)
>>
>
> Chrome is not willing to subject its users to such an easily avoidable
> "pain" simply as an incentive to other operators to help fix the badness.
> As much as users taking a latency hit of following long chains would
> incentivize recursives to follow the chains on their side, requiring long
> chain following would be an even stronger incentive to browsers and other
> stub clients to not support any HTTPSSVC alias following or maybe not
> support standardized HTTPSSVC at all.
>
> But I also disagree that all incentive for recursives to follow chains is
> removed if stubs only follow one alias link.  Even following that single
> alias in the stub is going to almost always be a bit slower than if the
> recursive does it.
>