Re: [DNSOP] Fundamental ANAME problems

Mark Andrews <marka@isc.org> Mon, 05 November 2018 19:03 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 314E3130E1A for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 11:03:22 -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 mIYw61svoajZ for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 11:03:20 -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 23169130E10 for <dnsop@ietf.org>; Mon, 5 Nov 2018 11:03:20 -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 2B5583AB8CD; Mon, 5 Nov 2018 19:03:19 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C5D38160094; Mon, 5 Nov 2018 19:03:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B06C3160093; Mon, 5 Nov 2018 19:03:18 +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 UrbDS8loKjdQ; Mon, 5 Nov 2018 19:03:18 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1C82B16005B; Mon, 5 Nov 2018 19:03:18 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (16A404)
In-Reply-To: <alpine.DEB.2.20.1811051717440.24450@grey.csi.cam.ac.uk>
Date: Tue, 6 Nov 2018 06:03:15 +1100
Cc: Joe Abley <jabley@hopcount.ca>, "dnsop@ietf.org WG" <dnsop@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BBCFDF8-62BC-4624-9D28-904DDC6EA71D@isc.org>
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <alpine.DEB.2.20.1811021543210.24450@grey.csi.cam.ac.uk> <20181105083526.GA12204@besserwisser.org> <7704C350-256A-42E3-B718-38FD449A2ADE@hopcount.ca> <alpine.DEB.2.20.1811051717440.24450@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/84w5p9Jz7UhtOVuwsWrjfOhOM24>
Subject: Re: [DNSOP] Fundamental ANAME problems
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 19:03:22 -0000

You can measure when to stop publishing A/AAAA records with HTTP by pointing the HTTP record at a different address.  Clients that are HTTP record aware will use one address and legacy clients will use the other address.

Mark
-- 
Mark Andrews

> On 6 Nov 2018, at 05:16, Tony Finch <dot@dotat.at>; wrote:
> 
> Joe Abley <jabley@hopcount.ca>; wrote:
>> On Nov 5, 2018, at 15:35, Måns Nilsson <mansaxel@besserwisser.org>; wrote:
>> 
>>>> I think a resolver-side or client-side alternative (like the various
>>>> web-specific record types we have been discussing) is defintely soemthing
>>>> we should aim for in the long term, but that isn't what this work is
>>>> about.
>>> 
>>> IMNSHO _any_ work on "fixing CNAMES at apex" that gets traction is
>>> a spanner in the works for what we seem to agree is a better solution.
>>> A interim fix will be deployed and stall every attempt at DTRT.
>> 
>> I think you are both right.
>> 
>> First, pragmatically speaking, there is clearly demand for something
>> that can do "CNAME at apex". DNS companies sell it, people buy it. It
>> already exists, but in as many flavours as there are providers that
>> support it, so interop is difficult. Having multiple providers is good;
>> interop makes that easier. Maybe there's work that the IETF could do
>> here, but I would suggest that a solution that nobody implements is not
>> much use.
> 
> Exactly.
> 
>> A reasonable starting point would be to survey the existing
>> implementations and ideally get the enterprise DNS providers responsible
>> to join in.
> 
> I've had informal chats with people from a number of big DNS providers.
> 
> * One or two big DNS providers see better interop as beneficial to
>  themselves as well as their customers. (I guess if two DNS providers
>  can get a customers to pay both of them then everyone is happy!)
> 
> * Standardization is a tempting opportunity to rationalize services and
>  reduce technical debt.
> 
> * Dynamic on-demand ANAME substitution is difficult to do with reliably
>  good performance at scale.
> 
> * Frequent UPDATEs are not something you want at large scale.
> 
> * One CDN said they wouldn't do general ANAME, only their existing
>  vertically-integrated setup where the CDN controls the (notional)
>  target.
> 
> So it's a mixture of great desire to have a solution to the problem, but
> the auth-side solutions are unappealing to many key players. My plan was
> basically to write a draft that waves its hands vigorously and says, yes!
> whatever you are doing can be made to fit ANAME! But that won't work if
> the response is, We aren't doing anything like ANAME and we don't want to
> do anything like THAT. So I'm feeling less confident that it's going to
> get consensus.
> 
>> Second, what is the longer-term solution that seems least likely to
>> cause painful intestinal cramping and bleeding eyes? I agree that if we
>> want a clean answer we should be looking at the clients, not the
>> authority servers.
> 
> Yes. I kind of feel in a weird superposition of states, believing both
> Evan's skepticism, and Ray's optimism.
> 
> I'm not sure what Web browser feature deployment timescales are like now.
> Picking a random example, from https://caniuse.com/#feat=flexbox it looks
> like full flexbox support started appearing in 2012 and it's now at about
> 96% availability (most of the gap being due to IE).
> 
> But for ANAME we're also concerned about other HTTP clients, especially
> dozens of programming-language-specific libraries and long-term-support
> enterpriseware with much slower deployment timescales. And ANAME is also
> useful for ssh clients, though they don't have such a large userbase, but
> ssh is very relevant to Tim's comments in his presentation about on-demand
> compute services.
> 
> Which implies that even if HTTP records become a thing, there will be a
> period of years during which zone admins will also have to provision
> address records for backwards compatibility. What we have seen again and
> again in this kind of situation is that operators will react with, What
> benefit do I get from the effort to learn this new thing and the extra
> work to support it? For HTTP records I fear the practical benefits in the
> short term will be zero.
> 
> Or maybe there are ways to get positive benefits. If ANAME stalls I'm
> inclined to implement auto-provisioning of address records driven by HTTP
> records instead, as a non-standard short-term backwards compatibility
> stop-gap.
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
> Biscay: Cyclonic, becoming westerly later, 5 to 7, increasing gale 8 or severe
> gale 9 for a time in south. Moderate or rough, occasionally very rough in
> south. Rain or thundery showers. Good, occasionally poor.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop