On Tue, Jun 11, 2019 at 6:35 PM Joe Abley <jab...@hopcount.ca> wrote:
> On Jun 11, 2019, at 20:04, Evan Hunt <e...@isc.org> wrote: > > > MHO, the ANAME is the real answer we're sending; the A and AAAA records > > are just friendly hand-holding for legacy servers. It doesn't make sense > > to me to demote the real answer into the additional section, any more > than > > it would have to move DNAME there. The protocol specificaions are clear > on > > this point - the more so considering we've already deployed DNAME - and > my > > sympathies for an implementation that got it wrong would be limited. > > I think DNAME provides a useful example. I think emulating DNAME's > demonstrated success in both being tolerated and interpreted correctly > is useful. > I agree that there is much from DNAME that can be useful to learn from. I think it helps to articulate what DNAME did, and why it worked (well, and at all): DNAME returned both DNAME and synthesized CNAME records, for queries received below the DNAME "cut" (query longer than the matching label for the DNAME). 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) When a client queried a recursive, there were two possible kinds of recursive: DNAME-aware, and DNAME-unaware. The same general answers were received, modulo the presence of the DNAME. If the client received, and understood, DNAME, it was effectively the same as if no CNAMEs had ever been sent or cached. If the client did not understand DNAME, then it would ignore any DNAME, and use the CNAME -- at that point, the question of whether the resolver spoke DNAME was more or less moot. The elegance of this was due to the fact that a synthesized CNAME was compatible with the namespace structure which might include a DNAME, as well as additional CNAMEs and/or DNAMEs. 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). >From recursive to client: An ANAME-aware resolver can maybe return a fully-resolved A/AAAA record, along with an ANAME (optionally with additional ANAME/CNAME/DNAME records chained) -- but I think testing this would strongly be advised. So, I suspect having the ANAME in the Answer section is worth experimenting (and the history of DNAME suggests it would not break badly). 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). Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
