Re: [DNSOP] Fundamental ANAME problems

Tony Finch <dot@dotat.at> Fri, 02 November 2018 16:39 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 34CA1130DFF for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 09:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb1pXX97omFK for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 09:39:11 -0700 (PDT)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 D8C9B130DFD for <dnsop@ietf.org>; Fri, 2 Nov 2018 09:39:10 -0700 (PDT)
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]:39390) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gIcTV-000A3n-0X (Exim 4.91) (return-path <dot@dotat.at>); Fri, 02 Nov 2018 16:39:09 +0000
Date: Fri, 2 Nov 2018 16:39:09 +0000
From: Tony Finch <dot@dotat.at>
To: Brian Dickson <brian.peter.dickson@gmail.com>
cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1811021543210.24450@grey.csi.cam.ac.uk>
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YjxhEh6g-DQ5s0hJ_xQMPlRcTao>
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: 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 <brian.peter.dickson@gmail.com>; 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
about.


Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
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.