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

Paul Ebersman <list-dnsop@dragon.net> Wed, 20 June 2018 02:09 UTC

Return-Path: <list-dnsop@dragon.net>
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 3ECA8130E7A for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 19:09:00 -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, 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 Vq0PL35yQ1Sm for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 19:08:58 -0700 (PDT)
Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242F3130E70 for <dnsop@ietf.org>; Tue, 19 Jun 2018 19:08:58 -0700 (PDT)
Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id 4AF8437402E9; Tue, 19 Jun 2018 19:08:56 -0700 (PDT)
Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 4C7A782B3CD; Tue, 19 Jun 2018 22:06:32 -0400 (EDT)
Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 46F2082B3CC; Tue, 19 Jun 2018 22:06:32 -0400 (EDT)
From: Paul Ebersman <list-dnsop@dragon.net>
To: David Conrad <drc@virtualized.org>
cc: dnsop@ietf.org
In-reply-to: <6213286F-10EB-400F-8333-3591C7A7B78B@virtualized.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>
Comments: In-reply-to David Conrad <drc@virtualized.org> message dated "Tue, 19 Jun 2018 15:44:46 -0700."
X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <43662.1529460392.1@fafnir.local>
Date: Tue, 19 Jun 2018 22:06:32 -0400
Message-Id: <20180620020632.4C7A782B3CD@fafnir.remote.dragon.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SdTRHvDwVVE4EYrjxTIdgr0fiq0>
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:09:01 -0000

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.