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

Brian Dickson <> Tue, 11 May 2021 22:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 250133A295D for <>; Tue, 11 May 2021 15:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1vSMJLiTjQMR for <>; Tue, 11 May 2021 15:44:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 648CC3A2959 for <>; Tue, 11 May 2021 15:44:08 -0700 (PDT)
Received: by with SMTP id x2so30898235lff.10 for <>; Tue, 11 May 2021 15:44:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=++AYbsNVTRGmhChmDcJuswolxUQm0tTl448c4X6gtb0=; b=t97tyIXpSyXsRu4V5EdXG3Xzs/hQ38EQk5qgzgGZF8crmHwPPxyq1oSQrpCgKE4WXs +nVwM+rzFtv4GYRcjq/C548a3bDZJhU4CqdvaNH9I49ZOFPEm6zsWeGEYST7YJeZLPDg k444EDTNaQTUbXRX/iRaHuWpPbQaUc9RilUoDqyMV+Hd73VRcLLjiIJjaw7To0VbCtVy jsW7a2zVi8TrGqxqsCTUYWeJrvnAGGLUdEJOG7miBWd8axHer3gUhiGATK41TANQIgWV KF1qbPUH5msF9Ij4OfqhcqdnpVK1SoQ1dPzoqTo3lw3vPnJb+ywfldhEybIJLPSlreFX GTFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=++AYbsNVTRGmhChmDcJuswolxUQm0tTl448c4X6gtb0=; b=sj/+V2LDlRafd0hlc8x4N+4lG5LlGsW6vnBm0rZUZ/SFZLUeNXRlnjOfmv3jN+fm0V Vxj0xtTarqW1RSaZYWSxYXrkw7CoeTsUGgnSm0CxC4hcPvMcLrqtEfAzRSA2x49T6KF2 eNOZgCM45rSwzRmEQTvzWjHhNVa9VYCXhQhpJYm8aKdrXlD0TXp0QsiixcL1FBn7I5M3 X+FB7x3AzCJmlWNjsnnt4TEuu74VN5ussnTCjJy+4iCHEucsExhQSQohsyGGffEdlqqO JdZJr2tFPzQmqfV179Ttgf7CiQtmLRHHMTvF/19fgF+UdH03kDlNcn8OHolNzVeA/Obq NI5g==
X-Gm-Message-State: AOAM533GyEIIRNKbAAmc5LrZyXulOp2/jqfsciFMwrAl3QavSpFbVoo+ Q1fR6ffr4yzvjepWySRWh9VHvRnfOVD1u3FJ+dA=
X-Google-Smtp-Source: ABdhPJz5ppa8RLJC+RFhLb4HiZP5SluLhclStDC1uXpbBfZ9iWVybfOottofYpNwduKxzvIVHQuSubIZzRhA6h59AVw=
X-Received: by 2002:a05:6512:118c:: with SMTP id g12mr22389708lfr.316.1620773044322; Tue, 11 May 2021 15:44:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Tue, 11 May 2021 15:43:52 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000009184e205c215a1da"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 May 2021 22:44:13 -0000

On Tue, May 11, 2021 at 2:49 PM Ben Schwartz <> wrote:

> On Tue, May 11, 2021 at 2:31 PM Brian Dickson <
>> 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 (
> ).

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

Or in that case, would each TargetName itself point to a name with an HTTPS
(or SVCB) record with its own SvcParams?
I.e. something like this: HTTPS 1 HTTPS 2

(and hosted on their respective domains) HTTPS 1 . alpn=h2,h3 A <A_RDATA> HTTPS 1 . alpn=h2,h3 A <A_RDATA> AAAA <AAAA_RDATA>

Is this something that is likely to be common or at least supported?
If so, it might make sense to put that in as an example of where and how
the actual ALPN binding part is done, where it differs from where the
TargetName is used to link domains.


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

Okay, I think the question/clarification above is what was missing.
Also, if the normal usage by CDN clients (versus CDN operators), where
multiple CDNs are used, does not require any SvcParams, that might make the
concern about the "key=value" lists vs "key,value" RRsets less onerous.