IETF Logo Mail Archive

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 17 September 2018 07:11 UTC

Return-Path: <bortzmeyer@nic.fr>
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 F2E04130E3D for <dnsop@ietfa.amsl.com>; Mon, 17 Sep 2018 00:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 fXbBg9A4KmBB for <dnsop@ietfa.amsl.com>; Mon, 17 Sep 2018 00:11:24 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 2F7F6130DF6 for <dnsop@ietf.org>; Mon, 17 Sep 2018 00:11:24 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 20E1C280131; Mon, 17 Sep 2018 09:11:22 +0200 (CEST)
Received: by mx4.nic.fr (Postfix, from userid 500) id 1A0082801B7; Mon, 17 Sep 2018 09:11:22 +0200 (CEST)
Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 12801280131; Mon, 17 Sep 2018 09:11:22 +0200 (CEST)
Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 0E5A6642C581; Mon, 17 Sep 2018 09:11:22 +0200 (CEST)
Received: by b12.nic.fr (Postfix, from userid 1000) id EF836401AE; Mon, 17 Sep 2018 09:11:21 +0200 (CEST)
Date: Mon, 17 Sep 2018 09:11:21 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Evan Hunt <each@isc.org>
Cc: Dan York <york@isoc.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>, Mukund Sivaraman <muks@mukund.org>
Message-ID: <20180917071121.lonvblxpzzb624ye@nic.fr>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <20180916095655.GA11121@jurassic> <0C475F3C-2220-4CC4-B564-47E7DF83AF6B@isoc.org> <20180917035134.GA34900@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180917035134.GA34900@isc.org>
X-Operating-System: Debian GNU/Linux 9.5
X-Kernel: Linux 4.9.0-6-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.9.17.65416
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9J9GmrZa8v4jMZJwf5AUkd5EZB8>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
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: Mon, 17 Sep 2018 07:11:29 -0000

On Mon, Sep 17, 2018 at 03:51:34AM +0000,
 Evan Hunt <each@isc.org> wrote 
 a message of 124 lines which said:

> I don't see how we can responsibly declare a new standard which, if
> followed, will break every prior implementation. Apex CNAME is the
> sort of solution that's clear, simple, and wrong.

+1

> We're going to need another type code.

Since the main use case is "people with a domain name such as
example.com, who wants https://example.com/ to actually work, and who
hosts the stuff at a CDN where the IP address is wildly variable so
they cannot use A or AAAA records", I suggest that this use case is
better solved by using SRV records for HTTP. True, it seems
unrealistic that it will be specified and deployed but it is also the
case for the DNS "CNAME at apex" change.

v2.23.0 | Report a Bug | By Email