Re: [DNSOP] SVCB chain lengths

[Eric Orth <[e-mail]>]

Maybe it would help if we scoped down any chain limiting:

1) Any chain limiting only applies to SVCB alias form, not CNAME.

CNAMEs already exist without a standardized limit.  Good or bad, too late
to change that without breaking things.  SVCB alias chains, as well as
aliasing apex names, are new and thus currently limited to zero.

2) Any chain limiting enforcement only applies to stubs following chains,
not recursives.

Recursives are already following CNAMEs without a standardized limit.
Speaking for the one stub resolver I know well, Chrome DNS, we don't
currently directly follow any CNAME links, relying on the recursive to do
it for us.  So the current CNAME chain limit in Chrome is also zero.  Any
chain following at all, CNAME or SVCB alias, is an increase of our current
practical limit of zero.

SVCB-aware recursives could resolve the chain without limit as they
currently do with CNAME.  Unlimited chain following anywhere seems
non-ideal to me, but my expertise is not on the recursive side so maybe
it's completely reasonable.  But if we're relying on the stubs to follow
chains (that may not have been followed there at all before) to account for
SVCB-unaware recursives, we should empower them to use chain limits
reasonable for them.  Being typically further away from results and with
less caching, unlimited chain following just does not seem reasonable for a
stub like Chrome, and it seems to us to have a big potential to be
detrimental to our users' experiences compared to the status quo of not
following any chains.

This point of scoping down is partly in response to Brian Dickson's reply
that SVCB alias should be first class and at least as powerful as CNAME.
Limiting chains in stubs makes chains practically limited everywhere for
most general cases because authoritatives will want to support the cases
where the recursive is SVCB-unaware.  But if there's going to be some "Flag
Day" by which all the recursives we care about add SVCB support without
limit, that will be the point after which the practical limit will be gone
and SVCB aliasing becomes fully empowered as a CNAME substitute.

3) Any chain limiting only applies to HTTPSSVC, not SVCB.

HTTPSSVC is a much more specific area where the usecases are more
understood.  I think when we say we don't see any usecases where needing
more than one alias makes sense, we're really only talking about the
well-understood HTTPS cases.  Anything else using SVCB is more generic and
hard to pin down whether or not any limits make sense or would be
reasonable.

And when you scope down chain limiting to just HTTPSSVC, the arguments
become less valid that aliasing could point to other organizations without
coordination over whether or not the one allowed alias is yet used.  In
HTTPS, the end server needs the cert for the domain.  There should be
coordination and trust between organizations in the alias chain, and the
organizations should be able to coordinate who is in charge of aliasing
from an apex domain.

>