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

[Ben Schwartz <[e-mail]>]

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

>
>
> On Thu, Aug 6, 2020 at 9:42 PM Mark Andrews <[e-mail]> 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.
>

I'm not sure I understand this problem.  The authoritative server could
deliver the whole SVCB RRSet with its signature, along with the chain from
following (just) one of the AliasMode RRs.  This is the behavior that is
required (in the current draft) of recursive resolvers (and clients).


> "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.

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).

...

>
> 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.
>

I wonder if the most popular option would be to allow either behavior, and
instruct recipients to check both sections.

>