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.dick...@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 <d...@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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
