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

Mukund Sivaraman <muks@mukund.org> Fri, 22 June 2018 19:13 UTC

Return-Path: <muks@mukund.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 3275E130ECE for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 12:13:46 -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 nD4MG6EmILJN for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 12:13:43 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF8F130EC0 for <dnsop@ietf.org>; Fri, 22 Jun 2018 12:13:43 -0700 (PDT)
Received: from jurassic (unknown [49.203.219.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id A5DB832C0935; Fri, 22 Jun 2018 19:13:37 +0000 (UTC)
Date: Sat, 23 Jun 2018 00:43:34 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Warren Kumari <warren@kumari.net>
Cc: jabley@automagic.org, Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>, Ray Bellis <ray@bellis.me.uk>
Message-ID: <20180622191334.GA15349@jurassic>
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> <1B7B2BB4-F0AE-4188-B89B-DF032BE7A237@automagic.org> <CAHw9_iKWhRjK6yzSSWVsCBqjdVfTnzVkUh8PMYC5nwQUb_=yvw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHw9_iKWhRjK6yzSSWVsCBqjdVfTnzVkUh8PMYC5nwQUb_=yvw@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IVF6Ak_xg1qMh1IRPt7X2dv1hzg>
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: Fri, 22 Jun 2018 19:13:46 -0000

On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote:
> On Fri, Jun 22, 2018 at 8:57 AM Joe Abley <jabley@automagic.org>; wrote:
> 
> > On 19 Jun 2018, at 17:03, Ray Bellis <ray@bellis.me.uk>; wrote:
> >
> > > 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...
> >
> > I think so long as there's a fallback for clients that don't yet have SRV
> > implemented (e.g. publish A/AAAA RRSets at the same owner name as the SRV
> > RRSet, and specify the behaviour by SRV-compliant servers in the event that
> > both are present) this is not a plausible engineering argument.
> >
> > Processing an SRV might require additional DNS lookups to get name -> SRV
> > -> SRV target -> address, but that's a one-time hit per TTL and I think
> > it's a stretch to paint that as definitely a problem. Modelling is required
> > and worst cases remain to be understood.
> >
> 
> ​It certainly is the ​case that a number of browser / large web properties
> have stated that an additional DNS lookup is a price that they are not
> willing to pay, especially for something not "critical".
> 
> I believe that this also would require firing off simultaneous lookups for
> SRV along with the A and AAAA (or, even worse, firing off a SRV, waiting
> for the "nooerror" error and *then* trying for the A / AAAA) and waiting
> for the long tail before you even know of you need to resolve the target.

With additional-from-cache (default on), BIND will return address of
target of SRV if it is already in cache. The second RTT will get
amortized. It won't take a lot to make it fetch and return the target
too, if it isn't found in cache.

[muks@jurassic ~]$ dig -t srv _xmpp-server._tcp.conference.banu.com

; <<>> DiG 9.11.3-RedHat-9.11.3-4.fc27 <<>> -t srv _xmpp-server._tcp.conference.banu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42270
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0578a97e07ef62a47b1993205b2d491527ff6b5b4672bea0 (good)
;; QUESTION SECTION:
;_xmpp-server._tcp.conference.banu.com. IN SRV

;; ANSWER SECTION:
_xmpp-server._tcp.conference.banu.com. 3543 IN SRV 0 0 5269 jabber.banu.com.

;; AUTHORITY SECTION:
banu.com.		3003	IN	NS	ns2.akira.org.
banu.com.		3003	IN	NS	ns1.banu.com.

;; ADDITIONAL SECTION:
jabber.banu.com.	3599	IN	A	46.4.129.229
ns2.akira.org.		3004	IN	A	46.4.129.253
ns1.banu.com.		3003	IN	A	46.4.83.135

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun 23 00:38:05 IST 2018
;; MSG SIZE  rcvd: 222

[muks@jurassic ~]$ 

		Mukund