IETF Logo Mail Archive

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Evan Hunt <each@isc.org> Thu, 20 February 2020 22:15 UTC

Return-Path: <each@isc.org>
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 33900120180 for <dnsop@ietfa.amsl.com>; Thu, 20 Feb 2020 14:15:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Jv0ZgT3PY-97 for <dnsop@ietfa.amsl.com>; Thu, 20 Feb 2020 14:15:18 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D523E12013D for <dnsop@ietf.org>; Thu, 20 Feb 2020 14:15:18 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed2.isc.org [IPv6:2001:4f8:1:f::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 304233AB003; Thu, 20 Feb 2020 22:15:17 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 22E369E86; Thu, 20 Feb 2020 22:15:17 +0000 (UTC)
Date: Thu, 20 Feb 2020 22:15:17 +0000
From: Evan Hunt <each@isc.org>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Cc: dnsop@ietf.org
Message-ID: <20200220221517.GA16177@isc.org>
References: <b34f1b0d-fa65-23d4-1b2b-761b965a2aae@knipp.de> <CAG8jCEzO7zrfL5G5CzdJ=c5wipJgqqHfyeA-a3-QjquoyPYgvg@mail.gmail.com> <3ead518d-f166-1c36-c3e9-18aeb355d160@pletterpet.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3ead518d-f166-1c36-c3e9-18aeb355d160@pletterpet.nl>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4Opr0chR6HVOHd4BdUuW86JJI7I>
Subject: Re: [DNSOP] status of the aname and svcb/httpsvc drafts
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: Thu, 20 Feb 2020 22:15:21 -0000

On Thu, Feb 20, 2020 at 09:29:31AM +0100, Matthijs Mekking wrote:
> ANAME was supposed to solve the CNAME at the apex problem and mitigate
> against DNS vendor lock in. Both SVCB and HTTPSSCV do not fix this problem.

CNAME at the apex wasn't really the problem. Getting browsers to display
content from the right CDN server was the problem. CNAME at the apex was a
hackish nonstandard solution that we were forced to adopt by browser
vendors' failure to do anything more sensible.

If browser folks *are* doing something more sensible now, as appears to
be the case, then we no longer have the problem ANAME was meant to solve,
and I'm content to let it pass into history.

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.

v2.23.0 | Report a Bug | By Email