Re: [DNSOP] Fundamental ANAME problems

[Bob Harold <[e-mail]>]

My thoughts at the bottom...

On Thu, Nov 1, 2018 at 6:34 PM Brian Dickson <[e-mail]>
wrote:

> Greetings, DNSOP folks.
>
> First, a disclaimer and perspective statement:
> These opinions are mine alone, and do not represent any official position
> of my employer.
> However, I will note that it is important to have the perspective of one
> segment of the DNS ecosystem, that of the authority operators (are also
> known as DNS hosting operators.)
> IMNSHO, authority operators provide a critical element of the DNS
> ecosystem, operating DNS zones for the vast majority of DNS registrants.
>
> The important element of this perspective is, that changes to how DNS
> operates and scales, if they have an adverse impact on authority operators
> (at scale), have potential knock-on impact to everyone.
> If (and I realize this is a big "if") changes are made which adversely
> affect the operation cost (regardless of whether it is direct or
> indirect/consequential) of operating authority services, this puts at risk
> the ability of registrants to operate their own zones (e.g. if there are
> fewer authority operators, or if prices skyrocket).
> This further puts at risk, the ongoing volume of DNS registrations, which
> impacts the viability of everyone else whose business relies on
> registration fees, directly or indirectly, including TLDs, CDNs, (non-DNS)
> hosting, and even ICANN itself.
> Caveat dnsops.
>
> Given the above, I feel it is important to point out several problems that
> are rooted in the requirement to dynamically update the sibling records
> that is present in the current design of ANAME. (This is the only real
> problem I see, but it's a doozie.)
>
> (The introduction text mentions some of these, but IMHO doesn't adequately
> address their impact.)
>
> 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.
>

> 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.
>

> 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.)
>
> To summarize:
> The requirement to maintain sibling records (A/AAAA) itself is absolutely
> a "camel back breaking" requirement. The issues are: frequency of updates
> required is externally imposed; either the correctness required by ANAME
> targets is broken (using single A/AAAA value regardless of anycast
> location), or the complexity of performing A/AAAA updates is compounded by
> at least NxM (N anycast locations of authority operatior, M disparate
> values provided in response to A/AAAA queries to the ANAME target); plus
> the added requirement of on-the-fly DNSSEC signing is a non-scalable and
> security-challenging non-starter.
>
> 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.
>
> 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.
> (I include clients as an option, since it is at least feasible to include
> client-based multiple-lookups as an alternative to "additional processing"
> that would otherwise be needed in resolvers.)
>
> 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. (Sorry for the badly written
> logic, english is not really well suited for branching logic.)
>
> There would still be a requirement on authority servers, but it would not
> provide a transparent backwards compatibility without updates to resolvers
> or clients. There would need to be SOME response to give to resolvers,
> telling them where to go and what to do. The only differences are, on the
> non-providing of sibling records, and the changes to response processing in
> which the new record type(s) are selected and returned. On the plus side,
> in this different model, the RRs would be basically constant, allowing the
> scaling of authority operators to be unaffected, and there would not be a
> requirement for dynamic updates or frequent/on-the-fly DNSSEC signing.
>
> There are several choices, and dependent on what those are, is what the
> logic change needed would be, where the new RRtype(s) could be used, and
> how resolvers and/or clients would handle the new responses.
>
> If the current limited ANAME (without sibling) is used, the logic would be
> to return it only if the corresponding query types (A or AAAA) are seen,
> there is no RRset of that type at the owner name, and there is an ANAME
> record. The processing on the authority, and resolver or client, would be
> pretty much as in the current draft, modulo not having the sibling record.
> If the response to an A/AAAA query is an ANAME, follow the chain until an
> A/AAAA record is found, or the chain breaks. If this is done by the
> resolver, special handling on TTL and new client queries would be necessary.
>
> Another option would be a similar type, maybe ACNAME (address CNAME),
> which could co-exist with other types, and could occur both at an apex and
> anywhere else in a zone. Same basic processing logic.
>
> A third option would be, for lack of a better term, WCRR, wildcard RR
> type, whose RDATA is an FQDN. The logical processing would be to add
> handling at the point where "NOERROR, NODATA" would otherwise be returned,
> right above the WILDCARD in the resolution process. If no match for QTYPE
> is found, check for WCRR type, and return that it found. Resolver handling
> would be the same; if a WCRR type is returned, replace the QNAME with the
> RDATA and re-start query processing.
>
> Client handling of these could be done via simultaneous queries for A (or
> AAAA) and ANAME (or WCRR), and following ANAME/WCRR replies to their target
> if no A/AAAA response is received and an ANAME/WCRR is received.
>
> (IMHO, the WCRR is a bit cleaner to implement on both authority and
> resolver, and is more forward-looking, i.e. handles other aliasing at other
> RRtypes as well, if needed.)
>
> The last option would be handling all of this junk in the browser, with
> either SRV, or whatever new RRTYPE is required that fixes the problem(s)
> with SRV that the HTTP folks require.
>
> Brian
>

I agree that unlimited updates could be an issue, but I think we can make
this work.

This might not be what the RFC says, but in reality I would likely handle
it this way:
I would treat this as a stepwise improvement.
I would suggest rolling this out in steps:
1. Allow adding ANAME records. Do not change any of the existing records,
and do not do any new updates.

Authoritative servers:


   - If the authoritative is not doing "proprietary A record updates" or
   "location based A records" (the premium feature you call "stupid DNS
   tricks") then there is no significant change in effort. They have a single
   set of A records for everyone, same as currently. Just also send the ANAME
   record.
   - If the authoritative is using "proprietary A record updates", it
   continues to do that. Just also send the ANAME record.

Resolvers:


   - If a resolver does not understand ANAME, nothing changes.
   - If a resolver does ANAME, it gets an immediate advantage.


2. ANAME style updates to the authoritative.

If not doing proprietary updates currently, this is a new feature, and
might require a premium cost.


   - Limit to one ANAME at the apex, or price per ANAME if needed.
   - Limit the update rate, or charge based on rate.

If currently using proprietary updates, convert to ANAME style updates, at
the same rate, and using the same DNSSEC signing mechanism that it used for
the proprietary updates. And charge the same amount.


3. Years later, when most all of the resolvers on the planet have updated
to understand ANAME, give users the option to remove the A and AAAA
records, and remove the update processing and charge less for the
simplified version. This might take decades and might never happen.

Another option to give users is a non-updating fallback A record, that
could point to a web redirect.  That saves all the hassle of updates.  (I
encourage users to redirect the apex to www... and the I CNAME www to the
CDN.  Some users don't want the www, but it solves the DNS problem.)

 My preference would be a *NAME record that specifies which record types it
applies to.  So one could delegate A and AAAA at apex to a web provider, MX
to a mail provider, etc.  That would also be valuable at non-apex names.
But I am happy to support ANAME as part of the solution.

-- 
Bob Harold