Hi Brian,
Thanks for your feedback on ANAME. Comments inline.
On 01-11-18 23:34, Brian Dickson wrote:
Greetings, DNSOP folks.
[...]
First, there is the issue of imposed update frequency.
The requirement on update rate, is imposed externally by whichever
entity operates the ANAME target. In other words, this is not under the
direct control of the zone operator, and is potentially a potentially
(and very likely) UNBOUNDED operational impact/cost.
As John already pointed out: You are in control of the update rate. It
may be that the target address records are changing frequently, but it
is up to the one that processes the ANAME to set an appropriate update
rate. So I don't see this as a particular worry.
The draft uses DNS UPDATE as an example and that may be a useful
scenario for one, but a red flag for another. However I will use ANAME
and no DNS UPDATE and I think my implementation of ANAME is still
compatible with the specification.
What I would like to see be changed in the draft is that were ANAME
processing occurs is more relaxed: Currently it focuses on this
happening at zone provisioning time (before the zone is loaded by the
primary), and mentions an optimization algorithm for resolvers that is
optional. However, there is some text in section 5.2 Alternatives that
the ANAME processing can occur on secondary servers which I think may
fit your DNS infrastructure better.
The point is that this draft should standardize the way ANAME is
processed, while giving flexibility on where processing can occur.
Second, this issue is compounded by scale.
The issue here is, that the larger the entity is that operates zones
with ANAMEs is, the larger the resulting impact. This is a new,
unanticipated, asymmetric cost. It has the definite potential to make
operating authority servers prohibitively costly.
I don't see any difference with existing proprietary implementations:
This statement is true for any CNAME-at-the-apex solution.
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.
[...]
As I said above: I agree that the draft should relax where ANAME
processing can occur. I don't see any reason why this processing can be
done at the entity that does the stupid DNS trick.
[...]
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.)
If you are going to do stupid tricks (aka tailored responses), you will
have to do on-the-fly DNSSEC signing anyway.
Side-note: we, as a community, have been pushing for wide-scale adoption
of DNSSEC; this definitely places a significant hurdle to adoption,
precisely in a wide-scale manner, i.e. to the vast majority of DNS
registrants. It is a big roadblock to DNSSEC adoption, and a move in the
wrong direction.
I disagree, I think it works pretty well with DNSSEC given the
requirement that ANAME processing should happen before DNSSEC signing.
This requirement is reasonable since ANAME processing is in the business
of tailoring RRsets and any changes made to the zone contents must
happen before signing.
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.
This points to the only logical places that MUST be part of any
apex-based chaining of resolution: resolvers, or clients.
John is right: It is very hard to rely on a solution that depends on
recursive name servers to be updated. Hence we look at a solution that
can be implemented at authorities.
Kind regards,
Matthijs
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
