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, 06 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
- [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems John Levine
- Re: [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems John R Levine
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Erik Nygren
- Re: [DNSOP] Fundamental ANAME problems Bob Harold
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Christian Huitema
- Re: [DNSOP] Fundamental ANAME problems John R Levine
- Re: [DNSOP] Fundamental ANAME problems Lanlan Pan
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- [DNSOP] CNAME at apex - a website publisher persp… Dan York
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems manu tman
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Jim Reid
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Mark Andrews
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Mark Andrews
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Olli Vanhoja
- Re: [DNSOP] Fundamental ANAME problems Thomas Peterson
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Dan York
- [DNSOP] Further ANAME minimization /\ Ray converg… Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Matthijs Mekking
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Richard Gibson
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Tim Wicinski
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Michael J. Sheldon
- Re: [DNSOP] Further ANAME minimization /\ Ray con… tjw ietf
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Kevin Darcy
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Tim Wicinski
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Bob Harold
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Thomas Peterson
- Re: [DNSOP] Fundamental ANAME problems Tim Wicinski