Re: [DNSOP] ANAME in answer or additional section [issue #62]

[Bob Harold <[e-mail]>]

On Thu, Jun 13, 2019 at 1:50 PM Brian Dickson <[e-mail]>
wrote:

>
>
> On Wed, Jun 12, 2019 at 1:11 AM Matthijs Mekking <[e-mail]>
> wrote:
>
>> Brian,
>>
>> Thanks for the detailed background on why DNAME worked. There are a few
>> things that caught my attention:
>>
>> > When a recursive queried an authority server, if it got back a DNAME
>> but did not understand it, it ignored the DNAME but processed the CNAME
>> (as if only the CNAME existed) (plus any other data like chained CNAMEs
>> or A/AAAA records)
>>
>> > All of this is unfortunate, because of the fact that there is no
>> genuinely backward compatible record similar to ANAME that can be used,
>> without a very strong likelihood of breaking things. From authority to
>> recursive: You can't return an ANAME and a CNAME (as a
>> backward-compatible rewrite signal that corresponds to the ANAME), since
>> the CNAME will effectively obscure other RRTYPEs that might coexist
>> (e.g. at the zone apex).
>>
>> This is fine, because that is not what we want: We would like to add the
>> ANAME in the answer section with the A/AAAA records (not a CNAME).
>>
>> > The real problem here, is the "other" record for backward
>> compatibility isn't a rewrite-type (such as CNAME or DNAME), but is a
>> "promoted" A/AAAA record of potentially limited utility and questionable
>> provenance (due to geo-ip stuff, TTL stuff, and RRSIG problems).
>>
>> I actually see the A/AAAA record as the backward compatibility records:
>> An ANAME-aware resolver would understand the ANAME and can act upon it,
>> an ANAME-unaware resolver will use the A/AAAA records that the
>> authoritative returned.
>>
>
> So, this is where the analogy to DNAME diverges from reality of ANAME, and
> IMHO is the the crux of one of the main problems with ANAME.
>
> In the DNAME/CNAME example, the A/AAAA records are returned ONLY IF the
> server that is authoritative for the DNAME is also authoritative for the
> DNAME "target" (right-hand-side/RDATA).
> If the DNAME auth server is not, it will only return DNAME+CNAME records.
>
> The only "legitimate" (in my opinion) reason that the ANAME authoritative
> server should also return A/AAAA records, is if it is also authoritative
> for the ANAME "target" (right-hand-side/RDATA).
>
> (And the reason that having the ANAME authoritative server obtain and
> return A/AAAA records itself leads to what I called:
>
>> potentially limited utility and questionable provenance (due to geo-ip
>> stuff, TTL stuff, and RRSIG problems).
>>
>
> I have elaborated on this problem previously, but will do so again for
> completeness/context:
>
>    - There can be differences (possibly significant differences) in the
>    results returned for resolution of the "target" between the ANAME
>    authoritative server, and the querying resolver.
>       - E.g. Any sort of "stupid DNS tricks" that return different values
>       based on either physical topology (anycast instance) or geo-ip
>       (client-subnet)
>       - That discrepancy can direct clients to a suboptimal server, where
>       suboptimal can even be, from a user perspective, badly broken (e..g. wrong
>       language, illegal content, etc.)
>    - The interactions on TTLs and the need for repeated lookups can have
>    adverse impacts on both clients, resolvers, and auth servers
>       - An auth server might want to use longer TTLs to reduce query
>       volume, for ANAME values that do not change frequently (A/AAAA TTL set to
>       same as ANAME TTL)
>       - The original A/AAAA TTL (for the "target" owner name's A/AAAA
>       RRDATA) might be short because it changes frequently (e.g. CDNs)
>    - If the "sibling" data is only a hint, non-upgraded resolvers will
>    serve A/AAAA records that are either poor (longer latency, higher loss),
>    wrong (incorrect language due to wrong CDN node), broken (long TTL -> wrong
>    server), or slow (requery required)
>
> I don't have a better suggestion on how to fix this within the context of
> ANAME; IMNSHO it is an intractable issue, a fundamental problem with ANAME
> if sibling records are required.
>
> Brian
>

I see two main cases:

   - ANAME replaces a CNAME record, so that other records can be attached
   to the same name. I don't think this is likely to be a big use case. In
   this case, all your concerns apply.


   - ANAME replaces A/AAAA records, most likely at a zone apex, where CNAME
   was desired but not allowed. I think this is the main case for ANAME. And
   in this case, the old A/AAAA records are returned as previously, but with
   the added ANAME record. Your concerns only apply if they already applied to
   the A/AAAA records - nothing has gotten any worse.

Is there another major case I am missing?

-- 
Bob Harold