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

Ben Schwartz <bemasc@google.com> Tue, 11 May 2021 21:49 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 8B9013A27C1 for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 14:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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, 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 Vyk3UoDlDNTi for <dnsop@ietfa.amsl.com>; Tue, 11 May 2021 14:49:31 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 691263A27BE for <dnsop@ietf.org>; Tue, 11 May 2021 14:49:31 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id l2so21565185wrm.9 for <dnsop@ietf.org>; Tue, 11 May 2021 14:49:31 -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=CAF8tWHgla1QVHfOxHR0x8UMp8D3ScTnVoCKubeRJbk=; b=dUD5LAy6fNSF2XQsyLVhOEbqLAiVTKftEZ7TnMMOBdepjYSDvv/TRkILYnhMT+CsbL c9kz8yHvkZHj4cYKjxnmfWFw82ftp/+LZXN4pDwYZPj6Pzn6HTNonR/JR9R4XMxbTk3n N7Eaa/LtefOhLk3nKIrWbCy5ppRyXkyLbpteTL3pQySmoxpn+6pZONq65ygIEikANkfT G0JjCAw0O+hKZ9SEPbkN7C8aHagwvT/YxCeEDixbhB0Zw260TQL7ofE7obWkpKB9yeYZ zGLSleRULht+f3YEPll2jT47+3Iu6kY3SmHOMVujUbnhYLlp9fb09c/5Enl0nffuou1r Y9hg==
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=CAF8tWHgla1QVHfOxHR0x8UMp8D3ScTnVoCKubeRJbk=; b=msF+GK50YlnNnxMx8CHfQ/WI8slq3PtGRtiV8CxHrkymjFiNy7/+Xq3JO27to206K0 Y0chQrebzMzQMBA17jMEIBpMnxyftqngzZxrAxjI2Q+th8drh8Vx9HchyZzMUzwyklNe Gyrr7au2DGDF5OLydziC2YSDc1QxDNgd+lC2FRdtBaBxRBVlWeUyj0GlkZC0Nh4HKlMm YTHkaVSzCtj8xaifnSQiHTD6zeFryxou+TPBuCvpm2CWev8oZWBS+4p7M+gBJWbEDzdy aeV6u773VLJ/5EHsHqpSPIdcn/tMP26UZWlUF1L01ivli4TskIL2Q5AZRab08is899cb NayQ==
X-Gm-Message-State: AOAM5330+qk6cR4ceTFyblm3MIan+wjSprhQ4xlT6DmrFZ67ziB8jg+9 Fv4oJ4ugliOkJvWGXFPdG9/VlSQeU9QkVtTx5P0J6g==
X-Google-Smtp-Source: ABdhPJxTLmHPPB40BYIFVj6Qu/SmXnFmfqN74H03jjOti+5RHm4mBcDyyxOhBk8UWxtN+IDh3efrztVGR/S/+aYrR7I=
X-Received: by 2002:adf:eec4:: with SMTP id a4mr41164455wrp.159.1620769768288; Tue, 11 May 2021 14:49:28 -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>
In-Reply-To: <CAH1iCipSweK0nv06kLH0EJJD8Khn9kZTqjYLzSzN86mjr0ZQdA@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 11 May 2021 14:49:16 -0700
Message-ID: <CAHbrMsC_bjKXXWNdsDDS4jADBG0GNMMgTZCpo3JryLdwQGfbXw@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="0000000000005249bd05c214ded4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VidF8WGn-SQ_kxXSlbzC2WCbitU>
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 21:49:35 -0000

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
).

...

> If the parameter sets were managed by the Web/CDN provider, and given a
> distinct DNS name (and referenced by name rather than value), the
> scalability of the bindings would likely improve, e.g. reference via CNAMEs
> (with the CNAME targets being long-lived and cacheable).
>

Yes, this is the goal of the draft, and the behavior documented by the
draft's CDN examples.


>