IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Tue, 19 June 2018 23:00 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 8F26E130E40 for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 16:00:11 -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 vm8mXlAJw3Yp for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 16:00:09 -0700 (PDT)
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 361A1130E35 for <dnsop@ietf.org>; Tue, 19 Jun 2018 16:00:09 -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 206413AB064; Tue, 19 Jun 2018 23:00:09 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D517E16008D; Tue, 19 Jun 2018 23:00:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B756916008E; Tue, 19 Jun 2018 23:00:08 +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 sBHGCRNhL5HR; Tue, 19 Jun 2018 23:00:08 +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 D3A78160053; Tue, 19 Jun 2018 23:00:07 +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: <6213286F-10EB-400F-8333-3591C7A7B78B@virtualized.org>
Date: Wed, 20 Jun 2018 09:00:07 +1000
Cc: Ray Bellis <ray@bellis.me.uk>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <99B5700D-3BE4-46E1-8B2D-391C1C804025@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>
To: David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/47M1DEG45f26BLHEeA9bslRZiyM>
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 23:00:13 -0000

> On 20 Jun 2018, at 8:44 am, David Conrad <drc@virtualized.org> wrote:
> 
> On Jun 19, 2018, at 2:03 PM, Ray Bellis <ray@bellis.me.uk> wrote:
>> 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.
> 
> I thought the more fundamental problem was the additional latency caused by the second lookup since SRV specified domain names as targets.

Yes, they keep coming up with theoretical issues which won’t be a issue in practice.  Nameservers put the address records of the server listed in the SRV record in the additional section so no second lookup is required.  If the address isn’t in the cache the nameserver can look it up while the SRV reply is in flight.  I’ve got code that does exactly that.  Took 30 minutes to write.  It’s just a different form of prefetch.  If they really want the additional section populated they can define a EDNS option or flag to say to do that.  At the moment most servers don’t follow CNAMEs when populating the additional section but that can also be done easily.

So one SRV query with all the rest of the data in the additional section.  Perfectly doable. Fallback to 2 queries with older name servers and a CNAME chain for the SRV target. 

> But maybe I’m misremembering.
> 
> Regads,
> -drc
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

v2.23.0 | Report a Bug | By Email