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.