Re: Quic: the elephant in the room

Viktor Dukhovni <> Mon, 12 April 2021 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D94B43A08A6 for <>; Mon, 12 Apr 2021 09:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NObbOraQ839d for <>; Mon, 12 Apr 2021 09:37:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C4B63A08A3 for <>; Mon, 12 Apr 2021 09:37:09 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 8AA0FB9AC4; Mon, 12 Apr 2021 12:37:08 -0400 (EDT)
Date: Mon, 12 Apr 2021 12:37:08 -0400
From: Viktor Dukhovni <>
Subject: Re: Quic: the elephant in the room
Message-ID: <>
References: <20210412021224.GP9612@localhost> <> <20210412002634.GO9612@localhost> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Apr 2021 16:37:11 -0000

On Mon, Apr 12, 2021 at 04:20:47PM +0000, Salz, Rich wrote:

> >   What do you mean by "in real-time"?
> I don't know what those other products consider, but I know five seconds happens.

In that case one may need short TTLs for the CNAMEs from the customer's
zone to the CDN zone, though this trades worse performance (higher
average latency) all the time, for faster cutover in rare situations.
One should weigh the tradeoffs with care.

> > And do they keep switching back and forth, or is a one time switch
> > stable for some days or longer?
> I've seen both short-term shifts (an hour or two), and long-term
> shifts (measured in days).

That does not sound like rapid back and worth (same ~5s timescale).
The new TTL for the retargetted temporary CDN can be shorter than

> I am sorry I cannot provide specifics, naming our customers for example.

No worries, I wasn't asking for anything nearly that specific.

Bottom line, if DANE/TLSA were adopted for HTTPS, it can be made to work
also with CDNs as described in this thread.

I would in fact recommed DNAME rather than CNAME in this case, because
it in one swoop aliases a subtree of the DNS to the CDN, which includes
both the address records and the TLSA records: IN DNAME www.somecdn.example.

The main limitation is that this only works for "leaf" names,
redirecting the zone apex is a separate problem, for which we're
inventing "HTTPS" records, ... and in the meantime some folks
are violating specs and publishing zone-apex CNAMEs, ...