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

[Matthijs Mekking <[e-mail]>]

Brian,

On 6/13/19 7:50 PM, Brian Dickson wrote:
> 
> 
> On Wed, Jun 12, 2019 at 1:11 AM Matthijs Mekking <[e-mail]
> <mailto:[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).

I disagree.  I do think an authoritative should be careful when doing a
target lookup and not recklessly replace its sibling records. But this
is all about how much trust you have in your ANAME resolution.


> (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.
>       o E.g. Any sort of "stupid DNS tricks" that return different
>         values based on either physical topology (anycast instance) or
>         geo-ip (client-subnet)>       o 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
>       o 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)
>       o The original A/AAAA TTL (for the "target" owner name's A/AAAA
>         RRDATA) might be short because it changes frequently (e.g. CDNs)

I agree with these issues, but I also think they are solvable with some
trickery. Perhaps some words in a Considerations section about that make
sense.


>   * 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)

The sibling data is not a hint, it is the actual answer that the
authoritative hands out for address queries. The ANAME target lookup
process is replacing the sibling address records with the target values.


Best regards,

Matthijs


> 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