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, 02 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.
- [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