On Thu, Aug 6, 2020 at 7:13 PM Ben Schwartz <bem...@google.com> wrote:
> Brian, > > I think arguing about the strength of the analogies to CNAME (Answer) vs > SRV (Additional) is going to be a slow path to consensus. Apart from that > analogy, I'm not sure I understand your motivating use case. Could you > write a small example zone where you think the "chain in Answer" behavior > has a clear advantage over "chain in Additional"? > Sure. Here are two very similar examples, where the first one I think is required to put the entire chain in the Answer for ${reasons}. (Take as ready any underscore prefixing needed to make this make sense...) whatever.example.com. CNAME example.com. example.com. SVCB 0 my-common-thing.example.com. my-common-thing.example.com. CNAME my-canonical-thing.example.com my-canonical-thing.example.com. SVCB <not=0> <stuff> whatever.example.com. CNAME example.com. example.com. SVCB 0 my-canonical-thing.example.com my-canonical-thing.example.com. SVCB <not=0> <stuff> The motivation here is that the optimization of adding in-bailiwick records should, to maximize the benefit to the resolver and to the authority server, process the second CNAME of the first example. However, if the placement of the in-bailiwick TargetName's records is in the Additional section, this is somewhat more complex. Either the CNAME processing has to happen before the TargetName and CNAME canonical name records are collectively placed in the Additional section, or the Additional section must now also process the CNAME. Not doing either of those would leave a "dangling CNAME" in the Additional section, which would then necessitate an additional query round-trip from the recursive to authoritative. Putting them all in the Answer section, means normal Answer section handling would basically handle the second CNAME "for free". This is all opportunistic behavior. It doesn't matter whether the extra records are added or not, so their absence from either section does not imply their non-existence, nor does it imply the authoritative server is aware or unaware of SVCB. I'm not sure I understand why having them be in the Answer section is any different from having them be in the Additional section, when it comes to their handling upon receipt by a recursive resolver. If the rules were "Put any SVCB records into the Answer section along with CNAME records found while obtaining them", then the only records that should be in the Additional section would be A/AAAA records and related DNSSEC records (and possibly CNAMEs found when obtaining the A/AAAA records?). I think this actually simplifies the processing: The ServiceForm SVCB record(s) might not be present (based on whether the authoritative is SVCB-aware and whether it is doing the addition of those records), but IF they are present, they are in the Answer section. This ALSO means that the only reason for anything being in the Additional section is if there are A or AAAA records returned, which (hopefully) implies the presence of a ServiceForm SVCB record. The only other reason A/AAAA records should be in the Additional section, is if there is a delegation, in which case there should be stuff in the Authority section too. So basically, it becomes: AliasForm only in Answer -> not in-bailiwick, or not SVCB-aware. Either way, another query is needed. AliasForm plus Service Form in Answer -> Check Additional for A/AAAA records, or query for them if not found (Both of the above possibly also include CNAMEs in the chain) CNAME chain only in the Answer -> not in bailiwick, need another query. No Data in the Answer, Authority has a delegation -> follow the delegation, possibly use Additional section for glue. I think this is pretty simple logic, and I don't see the problem... could you point out the problem if there is one? Brian >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop