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

Ray Bellis <ray@bellis.me.uk> Tue, 19 June 2018 21:03 UTC

Return-Path: <ray@bellis.me.uk>
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 DF306130F2C for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 14:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 q6b9Sn-Cfx9P for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 14:03:11 -0700 (PDT)
Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCEA130E09 for <dnsop@ietf.org>; Tue, 19 Jun 2018 14:03:10 -0700 (PDT)
Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:49745 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fVNmM-0006tY-HT (Exim 4.72) (return-path <ray@bellis.me.uk>); Tue, 19 Jun 2018 22:03:06 +0100
To: Tony Finch <dot@dotat.at>
Cc: dnsop@ietf.org
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk> <691FC45D-E5B6-4131-95BF-878520351F3A@gmail.com> <bf0ba568-1a18-f8cf-c1a0-3f547d642a78@bellis.me.uk> <0438207E-A4C2-434D-9507-9D9F54765CFB@puck.nether.net> <alpine.DEB.2.11.1806191649350.916@grey.csi.cam.ac.uk>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <9a0d1bae-dc58-99b5-40d1-caa7737dbfb1@bellis.me.uk>
Date: Tue, 19 Jun 2018 22:03:09 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1806191649350.916@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7IgKR9HgNBvqTVbYRPYqyr9HwD4>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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, 19 Jun 2018 21:03:13 -0000

On 19/06/2018 17:44, Tony Finch wrote:

> SRV should have been part of the fix (and it was invented early 
> enough to be!) but it wasn't a complete fix without support from the
> application protocols.

AIUI, a large part of the supposed issue with SRV was the inertia of the
installed base of browsers that wouldn't know how to access them.

Ironically the proposed fix seems to require upgrades to the
installed base of one of the most important network infrastructure
services on the planet.

Meanwhile, a very large portion of the installed base of web browsers
gets automatically and silently upgraded every month or so...

Ray