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

Mark Andrews <marka@isc.org> Wed, 20 June 2018 02:35 UTC

Return-Path: <marka@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 4F7A7130FC1 for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 19:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 XP7YfkW5j5Oa for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 19:35:41 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 39EB0130F8B for <dnsop@ietf.org>; Tue, 19 Jun 2018 19:35:41 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (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 0F8F63AB007; Wed, 20 Jun 2018 02:35:41 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AA448160053; Wed, 20 Jun 2018 02:35:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9406E160064; Wed, 20 Jun 2018 02:35:33 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IvGe340P-PbQ; Wed, 20 Jun 2018 02:35:33 +0000 (UTC)
Received: from rock-73422.home.lan (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 90F3D160053; Wed, 20 Jun 2018 02:35:32 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20180620020632.4C7A782B3CD@fafnir.remote.dragon.net>
Date: Wed, 20 Jun 2018 12:35:26 +1000
Cc: David Conrad <drc@virtualized.org>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DBDCCAEB-C0A0-44CF-84C1-9FAEF502B5FC@isc.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> <9a0d1bae-dc58-99b5-40d1-caa7737dbfb1@bellis.me.uk> <6213286F-10EB-400F-8333-3591C7A7B78B@virtualized.org> <20180620020632.4C7A782B3CD@fafnir.remote.dragon.net>
To: Paul Ebersman <list-dnsop@dragon.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZFvNb9TGNVKD5ZH9-8Y-rOzAtF4>
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: Wed, 20 Jun 2018 02:35:44 -0000

> On 20 Jun 2018, at 12:06 pm, Paul Ebersman <list-dnsop@dragon.net>; wrote:
> 
> bellis> AIUI, a large part of the supposed issue with SRV was the
> bellis> inertia of the installed base of browsers that wouldn't know how
> bellis> to access them.
> 
> drc> I thought the more fundamental problem was the additional latency
> drc> caused by the second lookup since SRV specified domain names as
> drc> targets.
> 
> You're not mis-remembering this. I hear this from the major browser
> folks every time we mention SRV. We may or may not think this isn't
> relevent (or that dozens of embedded objects are way slower to load on a
> web page) but it doesn't matter. If browser folks believe this and won't
> change, we aren't likely to convince them if we haven't by now.
> 
> SRV is a technically cleaner solution that will never get deployed...
> 
> While I understand cautions about changing CNAME, legacy issues,
> etc. I've come more and more to the camp that we lost this argument
> years ago and we should just let server software folks allow CNAME at
> apex and be done.
> 
> This is DNSOP. Operational. The world wants CNAME at apex. Let's give it
> to them.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

CNAME at the apex really will be the straw that broke the camel’s back.

To do it we would have to redo DNSSEC.  Rewrite thousands of lines of
code because the browser vendors are too pig headed to even attempt to
move to using SRV.  Really would it cost them anything to perform the
SRV lookups?  It’s not like they can’t do the two lookups in parallel.

One could even take _http._tcp and _https._tcp as a signal to fully
populate the additional section before returning.  That way you get
single query either way.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org