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

[Brian Dickson <[e-mail]>]

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.

"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