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
