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

[Bob Harold <[e-mail]>]

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

>
>
> On Thu, Jun 13, 2019 at 1:51 PM Bob Harold <[e-mail]> wrote:
>
>>
>> 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?
>>
>
> Yes, ANAME placed at apex, where no A/AAAA exists or existed. Typically
> when there is a "www" CNAME, and the zone owner wants to make a "magic apex
> CNAME" that points the same place as "www" currently does.
>
> I think that (addition of ANAME) is going to be 95% of the deployments,
> versus a 5% migration of already-existing proprietary RRTYPEs or
> pseudo-types (vertical integration) to ANAME. (If those weren't the
> expected levels of deployment, I don't the the efforts on ANAME would be
> worthwhile.)
>
> Brian
>

But in that case, the ANAME (with A/AAAA records) is a new addition, and
not worse that not having anything there.  I don't have any data, but I
expected that most cases would already have A/AAAA at the apex.

Does anyone have data on how many "www" names have or do not have A/AAAA
data for the label without the "www"?

-- 
Bob Harold