Re: [DNSOP] Fundamental ANAME problems
Tony Finch <dot@dotat.at> Mon, 05 November 2018 18:17 UTC
Return-Path: <dot@dotat.at>
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 A312A12008A for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 10:17:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 5LSjS8OYLfVB for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 10:17:00 -0800 (PST)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 80261127332 for <dnsop@ietf.org>; Mon, 5 Nov 2018 10:17:00 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:38934) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gJjQo-000oPO-hU (Exim 4.91) (return-path <dot@dotat.at>); Mon, 05 Nov 2018 18:16:58 +0000
Date: Mon, 05 Nov 2018 18:16:58 +0000
From: Tony Finch <dot@dotat.at>
To: Joe Abley <jabley@hopcount.ca>
cc: Måns Nilsson <mansaxel@besserwisser.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>
In-Reply-To: <7704C350-256A-42E3-B718-38FD449A2ADE@hopcount.ca>
Message-ID: <alpine.DEB.2.20.1811051717440.24450@grey.csi.cam.ac.uk>
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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-394262978-1541439309=:24450"
Content-ID: <alpine.DEB.2.20.1811051810300.24450@grey.csi.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v_n5JjwM38K3OjBrX7_zRskHahY>
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 18:17:02 -0000
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] 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