Re: [DNSOP] Fundamental ANAME problems

Mark Andrews <> Mon, 05 November 2018 19:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 314E3130E1A for <>; Mon, 5 Nov 2018 11:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mIYw61svoajZ for <>; Mon, 5 Nov 2018 11:03:20 -0800 (PST)
Received: from ( [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23169130E10 for <>; Mon, 5 Nov 2018 11:03:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B5583AB8CD; Mon, 5 Nov 2018 19:03:19 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTPS id C5D38160094; Mon, 5 Nov 2018 19:03:18 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B06C3160093; Mon, 5 Nov 2018 19:03:18 +0000 (UTC)
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id UrbDS8loKjdQ; Mon, 5 Nov 2018 19:03:18 +0000 (UTC)
Received: from [] ( []) by (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 <>
X-Mailer: iPhone Mail (16A404)
In-Reply-To: <>
Date: Tue, 06 Nov 2018 06:03:15 +1100
Cc: Joe Abley <>, " WG" <>, Brian Dickson <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Tony Finch <>
Archived-At: <>
Subject: Re: [DNSOP] Fundamental ANAME problems
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 Andrews

> On 6 Nov 2018, at 05:16, Tony Finch <> wrote:
> Joe Abley <> wrote:
>> On Nov 5, 2018, at 15:35, Måns Nilsson <> 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 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  <>
> 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