On Thu, Nov 1, 2018 at 6:34 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote:
> ... > > Third, there is an issue with the impact to anycast operation of zones > with ANAMEs, with respect to differentiated answers, based on topological > locations of anycast instances. > > There is currently an expectation on resolving a given name, that where > the name is ultimately served (at the end of a *NAME chain) by an entity > doing "stupid DNS tricks" (e.g. CDNs), that the answer provided is > topologically appropriate, i.e. gives the "best" answer based on resolver > (or in the case of client-subnet, client) location. > When done using CNAMEs, the resolver is the entity following the chain, > and does so in a topologically consistent manner. Each resolver instance > querying a sequence of anycast authorities which return respective CNAMEs, > gets its unique, topologically-appropriate answers, and there is no > requirement or expectation that resolvers in topologically distinct > locations have any mutual consistency. > 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.) > I share your concerns on how useful ANAME will be or whether it will actually solve problems. To make matters worse, for an authority to use ANAME in conjunction with a CDN that returns dynamic responses for mapping and load balancing, it's likely that the *authority* would also need to use ECS with client subnet information for the A/AAAA lookups (as is done by some of the largest anycast open resolver services) but then dynamically resign the results. This means online ECS lookups with caching (often of names/records with very short TTLs) and online signing which open up quite a few perf, scaling, and security challenges such as DDoS-attack-resilience. One of the reason that at least some CDNs have built integrated-stack solutions to DNS authorities that can do CNAME collapsing internally is that this allows them to do proprietary optimizations to resolve some of the issues described here. If a stated goal of ANAME is to allow authorities distinct from a CDN to follow a CNAME chain to a given CDN and then incorporate the results in their answer for the zone apex (to improve vendor agnosticism), it may also be worth really validating whether the design will scale and be performant and interoperate with such CDNs. Since this is being configured by the owner of a zone, they are likely incentivized to make sure that whatever is configured actually works well and provides good end-user overall performance (not just DNS lookup performance). Not incorporating client information (eg, via ECS) into responses and/or substantially increasing TTLs are likely to cause significant overall problems. The result may then be "who will actually use ANAME as described here and for what?". Exploring some of the alternatives as you suggest may result in slower-to-deploy but overall more widely adoptable approaches. Erik
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop