Re: [DNSOP] Minimum viable ANAME

Mark Andrews <marka@isc.org> Mon, 05 November 2018 05:27 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 D1169128CF2 for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 21:27:23 -0800 (PST)
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 iP2wGpiww5ck for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 21:27:21 -0800 (PST)
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 DFBD5128A6E for <dnsop@ietf.org>; Sun, 4 Nov 2018 21:27:21 -0800 (PST)
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 803783AB5A5; Mon, 5 Nov 2018 05:27:21 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5730F160076; Mon, 5 Nov 2018 05:27:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 43B5D160077; Mon, 5 Nov 2018 05:27:21 +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 fIAYFyDXqSAM; Mon, 5 Nov 2018 05:27:21 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 28FB2160076; Mon, 5 Nov 2018 05:27:19 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <5BDFB3D0.3030508@redbarn.org>
Date: Mon, 5 Nov 2018 16:27:17 +1100
Cc: Ray Bellis <ray@bellis.me.uk>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C744CCB-EC8F-464B-85F9-4D61C85EE640@isc.org>
References: <20180919201401.8E0C220051382A@ary.qy> <08C8A740-D09B-4577-AF2A-79225EDB526B@dotat.at> <20180920061343.GA754@jurassic> <E944887D-51ED-41A0-AC5A-3076743620D8@isoc.org> <acef1f69-8e4f-52cc-dca5-3ada9446e0ee@bellis.me.uk> <5BDE34E3.5030602@redbarn.org> <a149f8ba-7350-327f-ab13-8c6eeb76f2f5@bellis.me.uk> <a85e1f2e-4feb-3f9e-fb8c-62214de98fd2@bellis.me.uk> <5BDEA757.7040208@redbarn.org> <C536FA41-4E24-4552-9139-8AB9B741E009@isc.org> <5BDFB3D0.3030508@redbarn.org>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3sExbHffcNo3nWW32U4viLOlYm4>
Subject: Re: [DNSOP] Minimum viable ANAME
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 05 Nov 2018 05:27:24 -0000


> On 5 Nov 2018, at 2:06 pm, Paul Vixie <paul@redbarn.org>; wrote:
> 
> 
> 
> Mark Andrews wrote:
>> 
>>> On 4 Nov 2018, at 7:01 pm, Paul Vixie<paul@redbarn.org>;  wrote:
> ...
>>> that would be a mistake. we are hitting for average here not power
>>> -- the behaviour to optimize for is whatever's most common. if the
>>> SRV is used, the AAAA or A RRsets will be fetched, and thus cached.
>>> if the SRV is only used once, that caching effort will be wasted.
>>> if the SRV is used many times, then the dominant use case will be
>>> that the additional data is found in cache because the client
>>> caused this to be so.
>> 
>> The main objection to SRV was the double RTT to the recursive server.
>> Fetching the address records before returning will speed up the sites
>> that are not talked to regularly and will not slow down the sites
>> that are talked to regularly as the values will already be in cache.
> 
> i'll try again differently. such a fetch would add logic branches and
> state and network information, to no purpose whatsoever.


> if the stub who asked the SRV question does not receive the addresses it needs in additional data, it will query for them. that will put those addresses in cache, so that on subsequent same-SRV questions, it will be present.

And that requires 2 RTT’s from the client which, despite being only a few ms normally, has been enough for the HTTP folks to refuses to deploy anything other than CNAME for ~2 decades now.

> if the SRV is never fetched again, then there's no win to be had.

The win is loosing the extra RTT from the stub to the recursive server.

> popular SRV answers will be overwhelmingly dominated by the second and subsequent responses, which will all include the additional data.

> a recursive should only fetch what it needs for its own operations, so for example if it knows an NS RR but not the corresponding AAAA or A RR, it can fetch those. and for qname minimization it can make the requisite diagnostic queries. but it should NOT fetch just because it lacks additional data. the stubs should cause those fetches.

And then we get back to the complaints from the HTTP side saying the SRV takes longer than CNAME, which is valid for the first lookup if you don’t fetch the additional records before returning.

> -- 
> P Vixie

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