Re: [DNSOP] Fundamental ANAME problems

Tony Finch <> Fri, 02 November 2018 16:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34CA1130DFF for <>; Fri, 2 Nov 2018 09:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rb1pXX97omFK for <>; Fri, 2 Nov 2018 09:39:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8C9B130DFD for <>; Fri, 2 Nov 2018 09:39:10 -0700 (PDT)
X-Cam-AntiVirus: no malware found
Received: from ([]:39390) by ( []:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gIcTV-000A3n-0X (Exim 4.91) (return-path <>); Fri, 02 Nov 2018 16:39:09 +0000
Date: Fri, 02 Nov 2018 16:39:09 +0000
From: Tony Finch <>
To: Brian Dickson <>
cc: " WG" <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
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: Fri, 02 Nov 2018 16:39:13 -0000

It's really good to see more discussion about ANAME.

The current draft doesn't discuss scaling issues because my main concern
was to get the rewrite done, so there are a number of gaps, e.g. I deleted
the "operational considerations" section. But that doesn't mean I was
unaware of the problem :-)

Brian Dickson <> wrote:

> ANAME places the authority servers in an anycast cloud, in a "Hobsons
> choice" scenario. Either a single, globally identical sibling value is
> replicated to the anycast instances (which violates the expectation of
> resolvers regarding "best" answer), or each anycast instance needs to do
> its own sibling maintenance (with all that implies, including on-the-fly
> DNSSEC signing), or the anycast cloud now has to maintain its own set of
> divergent, signed answers at the master, and add all the complexity of
> distributing and answering based on resolver topological placement. (The
> last two have significant risk and operational complexity, multiplied by
> the volume of zones served, and impacted by the size of the anycast cloud.)
> To summarize:
> The requirement to maintain sibling records (A/AAAA) itself is absolutely a
> "camel back breaking" requirement.

I think this is the meat of your objection.

I'm aware that most existing ANAME-like implementations are tailored
for target addresses that are controlled by the DNS hosting provider,
which makes it a lot easier :-) I think that's what you were referring to
on your other message about vertical integration.

Next most common is dynamic lookups of arbitrary targets. This is probably
easier to scale to a very large number of zones with ANAMEs than an
UPDATE-style implementation, but I gather from talking to various people
that it's still fiendish. (And that's why the WG consensus is not to
require a dynamic implementation style.)

(BTW, I live in the same city as Hobson did, so as a pedant I must point
out that Hobson's choice was one option, take it or go without. At least
for ANAME there are multiple implementation strategies, however
unpalatable they all are!)

> What are the alternatives?
> Fundamentally, the behavior that is desired that we are collectively trying
> to preserve, is that of resolver-based *NAME chain resolution, just with
> the ability to do so at the apex of a zone.

I'm not sure why you say "preserve" here, because none of the existing
ANAME-alikes work that way.

A key aim of this draft is to provide something that works similar enough
to existing ANAME-like features, to give zone owners portability across
providers. I spoke to a number of DNS providers in Amsterdam who have
ANAME-like features and who are keen to improve interoperability.

> Ultimately, this means any solution that has this characteristic, can only
> provide backwards compatibility to clients, if resolvers are updated, or
> alternatively, if clients are updated to do whatever is required that
> resolvers which aren't updated won't do.

It's really important that ANAME can be deployed on authoritative servers
without co-operation from anyone else, especially not resolvers. (After
all, that's how the existing implementations work.)

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

f.anthony.n.finch  <>
Malin, Hebrides, Bailey: South or southeast 6 to gale 8, increasing severe
gale 9 at times. Moderate or rough, becoming rough or very rough, occasionally
high later. Rain. Good, occasionally poor.