On Thu, Jun 13, 2019 at 6:34 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote:
> > > On Thu, Jun 13, 2019 at 1:51 PM Bob Harold <rharo...@umich.edu> wrote: > >> >> On Thu, Jun 13, 2019 at 1:50 PM Brian Dickson < >> brian.peter.dick...@gmail.com> wrote: >> >>> >>> >>> 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 >>> >> >> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
