Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

[Brian Dickson <[e-mail]>]

On Fri, Aug 7, 2020 at 7:42 AM Ben Schwartz <[e-mail]> wrote:

>
>
> On Fri, Aug 7, 2020 at 4:14 AM Brian Dickson <
> [e-mail]> 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