Brian, On 6/13/19 7:50 PM, Brian Dickson wrote: > > > On Wed, Jun 12, 2019 at 1:11 AM Matthijs Mekking <matth...@pletterpet.nl > <mailto: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).
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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
