On Thu, Aug 6, 2020 at 9:42 PM Mark Andrews <[email protected]> wrote: > > Sorry you just broke DNSSEC if there are more than one AliasForm records. > More than one is permitted with the same name. >
Good point. "More than one is permitted" is the case only because of the current spec. I don't see any explanation for why this is (or needs to be) the case. What would be wrong with changing the spec to prohibit more than one AliasForm record at a given name? Now, suppose only one AliasForm is permitted (just like CNAME), what downside would there be? The handling of multiple AliasForms at a given name should be handled in the same way that having more than one CNAME is handled. That seems like it wouldn't be hard. And as far as I can tell, the ServiceForm is the thing for handling the multi-CDN, availability, etc. issues. It's the right tool for the multiple RR situation. > And how do you do that with a graph? This is the multiple QNAME problem. > So, other than at the terminus of the ultimate set of ServiceForm SVCBs, why should this even be a graph, rather than a chain? Does reducing this to a chain fix the multiple QNAME problem? The ServiceForm records all clearly need to be processed so that the correct set of answers is returned to the client. I'm not proposing any changes to that part of the spec. Having only a single AliasForm record allowed at any given owner name would avoid any forking. Additionally, much of the text and the examples suggests that where possible zone administrators should use CNAME instead of AliasForm, i.e. everywhere other than at a zone apex. That would seem incompatible with the alternative of intentionally allowing or encouraging multiple AliasForm records (which, unlike ServiceForm records, do not have a priority field.) I think it's not much of a stretch to change the SHOULD to a MUST (on only one AliasForm), and I think that fixes a lot of the remaining issues. I'm willing to drop the Answer vs Additional section for in-bailiwick TargetName (plus A/AAAA) placement. (However, I'm not the only person in the WG other than the authors; others may have stronger feelings about this, since at least one person concurred with my original post.) It's up to the WG on this latter issue (placement), I'm good with whatever the consensus is. Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
