Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Ben Schwartz <bemasc@google.com> Tue, 11 May 2021 23:00 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 92FA93A29F7 for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 16:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.588
X-Spam-Level:
X-Spam-Status: No, score=-9.588 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_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 f3ZzAE6yK_JI for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 16:00:52 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 EF9353A2A03 for <dnsop@ietf.org>; Tue, 11 May 2021 16:00:51 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id n2so21760103wrm.0 for <dnsop@ietf.org>; Tue, 11 May 2021 16:00:51 -0700 (PDT)
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=/JmecYGS9jPJkFUhKJxnsQu/HyWatslf4DdIDsaOhdQ=; b=fGr0taoEk9Tq1pNTpAmXfm44bzd3KBwabNQeZJn3dpI8UchX+aHKCCNXMqRSD3GR7l zBqRvNcLn/O4lc4rrbnj2fNJtPyybJWMSrkGql2hQKc90UYjYhKjF4hh3HvoC8TGetLh uaHgRTdXxdbCbZ30C7pjXsV9Rl/557CYMGGNrkvwwEHaThQ0QL3TFUGzLCa8WOoyy5bJ 669YVllISm7IAck5SZqCsYGabDZZl47JjHJ1gYnA6Eh33ZdJNCelhQUaUaYykE6sfN8k EQj42SZTfSM8SAKYKCqCkfze2UC5d5FKKBk2V8KdeqCMZIqyyv2Y+IMWfyxziR5xCuF5 BwRw==
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=/JmecYGS9jPJkFUhKJxnsQu/HyWatslf4DdIDsaOhdQ=; b=fEYHVTb2flGPq6OJ8BIrmCFBI31C19j2JPA+4mxNQ0ic6986zsfYURtfi776DMIcw2 d+Ugaid/DzEbk2/Zcl2sTyy252V73qVMolkispHXTnPI3OTlFYFiLKTIs6D+tfAwu7+l HfkxCWU8G5N1WKEczknOQJkKlhMIV6NP0nnptDAmDDymzlqxRmwC8VypFVR6AMHA0zzE 0io0MqAeA1Mdp/8OEUJIr5RdjH5N45ZYdW6XZ4V/vlOEshLVyGzp5zmWEzCkgo0lh5jp zFEJgmuz/v//uoOaXQ1pAbI6DTw1dCnyli1dJVTvPEgiJyY4k+68NglGOhKXn2EwZAg8 TQMQ==
X-Gm-Message-State: AOAM530yYHqXsnuTV5yaEedclmvlxZIJH8GxHm/6peL8bGdxA/48Gnbz 5x7qAZYJOpk5B8kHy5aNWHAqjlhgmWESS/tfJ2WtEA==
X-Google-Smtp-Source: ABdhPJzta12lmjEaqoMLxF03AFbaPrxdIMdsNU3IyfEZuwXSdLNfdWK0sAYjTIu1gn2ehkvq7mGVRZsUQRbGnxzevlc=
X-Received: by 2002:a5d:4a81:: with SMTP id o1mr6466702wrq.177.1620774049313; Tue, 11 May 2021 16:00:49 -0700 (PDT)
MIME-Version: 1.0
References: <F4CE48A1-7AB0-45D0-97FF-158CE3A04EE1@icann.org> <3EE971EE-0777-44D6-9CD2-771B92FFE938@hopcount.ca> <1d822219-8ab9-2cb7-d0a4-9b8afc39058d@powerdns.com> <2952D408-117B-40D0-B859-7A8E4111629E@hopcount.ca> <CAHbrMsD+uiaYQ8i58VRjF=3AtW9uAoAtgbKzNzrPZC3QCmD2pQ@mail.gmail.com> <CAH1iCirykCpqkQEizYUBYMJEXMYRGkWvnzyo-jP=XOT-4fP-EA@mail.gmail.com> <123fd984-a3e1-0d09-b745-9a7ed6260759@nic.cz> <CAHbrMsCrf8GS3N=HF53X-M0oq09yw_vKGFLU_qA6wt94-+vNXg@mail.gmail.com> <07FE2C2B-10C4-47B0-BFF7-AD8E980A2E26@hopcount.ca> <CAHbrMsB6qGs2QsvYMC9j2ahWAR80gdcsDbgihQiXYXG03OY9qQ@mail.gmail.com> <D72B8D52-50F8-457F-B123-D303F4865557@hopcount.ca> <CAHbrMsDzWjib5zfRpr3hJk4bjXjGAq9Z2pymPoLac9rJZPbWAQ@mail.gmail.com> <CAH1iCipSweK0nv06kLH0EJJD8Khn9kZTqjYLzSzN86mjr0ZQdA@mail.gmail.com> <CAHbrMsC_bjKXXWNdsDDS4jADBG0GNMMgTZCpo3JryLdwQGfbXw@mail.gmail.com> <CAH1iCipTh2iQZ8V=rnfJpomDrMGaMmHMxVs7=YEUYb6CFOAtTg@mail.gmail.com>
In-Reply-To: <CAH1iCipTh2iQZ8V=rnfJpomDrMGaMmHMxVs7=YEUYb6CFOAtTg@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 11 May 2021 16:00:37 -0700
Message-ID: <CAHbrMsCgG2joydsZ80DLNYP_qNOVKSqWUd_AR7Kop7w_sYBqLA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000007e9fa305c215dd57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MpT_m5Mb-ThHCCdeKTzQU_t-Lzo>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
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: Tue, 11 May 2021 23:01:06 -0000

On Tue, May 11, 2021 at 3:44 PM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

>
>
> On Tue, May 11, 2021 at 2:49 PM Ben Schwartz <bemasc@google.com> wrote:
>
>>
>>
>> On Tue, May 11, 2021 at 2:31 PM Brian Dickson <
>> brian.peter.dickson@gmail.com> wrote:
>> ...
>>
>>> Another way to put it is, the SvcParameters are actually bound to the
>>> TargetName, not the owner name of the HTTPS record, and the Web/CDN
>>> provider is (semantically speaking, not DNS-speaking) "authoritative" for
>>> those parameters.
>>>
>>> Is this accurate?
>>>
>>
>> It sounds like one of the deployment arrangements that is anticipated by
>> the draft.
>> ...
>>
>>> In the current design, the domain owner needs to, in effect, do a
>>> copy/paste from each Web/CDN providers' information into the domain owner's
>>> own DNS zone, including the TargetName and SvcParameters.
>>>
>>
>> No, as you noted, this is definitely a bad idea, and is not required or
>> recommended in the draft.  Instead, the domain owner should use CNAME and
>> AliasMode records to alias to an HTTPS ServiceMode record maintained by the
>> CDN.  See the Examples section (
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html#name-examples
>> ).
>>
>>
>
> I'm maybe confused here... I thought the AliasMode (or CNAME) would only
> work if there is exactly one CDN provider.
> What would the domain owner need to do for having two CDN providers, at
> different Priority levels (or at the same Priority level)?
>

Multi-CDN support is described here:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html#name-multi-cdn
It works exactly like multi-CDN works today, juggling multiple CNAMEs to
avoid copying CDN IPs into the customer zone.

I think a standardized mechanism to simplify management of this arrangement
might be useful, but it is largely independent of SVCB and can be developed
separately if there is interest.

>