On Wed, Jun 12, 2019 at 1:11 AM Matthijs Mekking <matth...@pletterpet.nl>
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
