On Fri, Aug 7, 2020 at 7:42 AM Ben Schwartz <[email protected]> wrote:
> > > On Fri, Aug 7, 2020 at 4:14 AM Brian Dickson < > [email protected]> wrote: > > >> "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? >> > > The current text says "SVCB RRSets SHOULD only have a single resource > record in AliasMode." Early drafts say "RRSets MUST only have a single > resource record in this form." ( > https://www.ietf.org/archive/id/draft-nygren-httpbis-httpssvc-03.txt). I > believe this was changed because declaring that RRSets MUST only have one > record, and also declaring what recipients should do if there are more than > one, seemed like a contradiction. Also, round-robin AliasForm seemed > harmless, and potentially useful for multi-CDN. > > No, it isn't a contradiction. If it is forbidden, you have to handle non-compliance. That's just protocol 101. Also, it may be messy to try to be prescriptive on what to do? Maybe just provide loose guidance to implementers to the effect of, "You have to handle this situation for multiple CNAMEs. Using the same logic for that is the right thing to do." Even if how multiple CNAMEs isn't necessarily well spelled out in the RFCs, it isn't a problem that I see causing major problems on various DNS implementations (at least as far as I know). The same guidance would be applicable regardless of where in the ecosystem the issues are handled, from APIs to UIs to auth to recursive to client. Not sure how anyone feels about that as guidance, but I think it would make the document pretty easy to understand and minimize any confusion. > 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. >> > > Correct, ServiceForm is the intended solution for multi-CDN. Using > round-robin AliasForm for multi-CDN would give less fallback capability to > clients (they could only use one CDN or the other), but would reduce > coupling between the CDN and customer (no need to copy SvcParams into the > customer zones, where they might be hard to update). > > So, it's really only a minor convenience thing, not a blocker per se. I.e. making multiple AliasForm entries a "MUST NOT", would not prevent someone from being able to use multiple CDNs, it would just be slightly less friendly/flexible. My issue with the round-robin impact is doing so would very likely make diagnosing or solving problems when multiple CDNs are involved, extremely difficult and confusing, at the one place where you really don't want things to be confusing or difficult to diagnose. It's a non-deterministic behavior in a place without any real way to figure out what is happening. One of the main benefits of the parameters in the ServiceForm is that you can re-prioritize if equal-weight stuff is having problems, and that allows both diagnosis and fixes to problems that are discovered (lower the weight of the broken thing.) I think bringing back the prohibition on multiple AliasForm records at an owner name is the wisest choice. Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
