Re: [DNSOP] SVCB chain lengths

[Brian Dickson <[e-mail]>]

On Mon, Dec 23, 2019 at 12:22 PM Eric Orth <ericorth=
[e-mail]> wrote:

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

Disagree. These alias-form changes are not yet standardized, and the limits
(zero or otherwise) are "vacuously defined". I.e. the limit of the length
of a sequence which is undefined, is itself undefined.

They are currently limited to not exist, so we can't make any assertions
about the length of chains of these things (yet).

We are presently (here, in this conversation) discussing what limits to
apply, if any. Let's start from there...


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

It is completely reasonable. Reminder: the chain following stuff only gets
done on the first reference(s) to client-side rewriting that occurs (CNAME,
DNAME, and new alias-form), and the recursive side CACHES THOSE RESULTS AND
RETURNS THEM.

I.e. After the first stub asks for something that requires chain following,
the FULL CHAIN is cached, and the next stub gets the WHOLE CHAIN. (Modulo
stupid DNS tricks like ECS.)


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

Why? If you want to make the argument, you need to solidly justify a
difference in behavior between two things implementing the same standard:
stubs with unaware recursives, vs stubs with aware recursives.

There are substantial implications to having any such distinction.

Specifically, this means that chains ARE PROHIBITED (for length > N) when
stubs use unaware recursives, but NOT PROHIBITED (of any length) when stubs
use aware recursives.

This in turn, places a burden on the entire DNS ecosystem (and in
particular, zone owners, operators, and intra-provider heterogenous
deployments, aka non-vertical-integrated zone owners with multiple
providers, e.g. CDN vs Hosting vs DNS).

Wanting things to resolve fast CANNOT trump the other requirements from the
larger DNS community.


> 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 puts the necessary and appropriate pressure on stub clients to their
resolver operators, to deploy Alias-form aware resolvers.

Putting in place (IMHO) hacks, to reduce or eliminate that "pain", removes
ANY incentive for resolver operators to actually deploy this stuff.

If resolver operators NEVER deploy this stuff, we may as well chuck it
before we adopt this, since there will be literally zero benefit, while
creating non-trivial amounts of cost (in terms of stub client
implementations, authority-server implementations, zone owner deployments,
etc.)

BTW, I'm strongly in favor of this getting adopted, and getting deployed in
recursive resolvers.

Thus, I'm in favor of NOT having alias-form limits, even on the stubs. This
will lead to much faster adoption, compared to "Real Soon Now", "Some Day",
"Eventually", and "We Never Promised To Do That".
(The latter set of responses paraphrased from an un-named registrar who
eventually reneged on "promises" to deploy DNSSEC support.)


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

Correct. The issue is putting substantial PRACTICAL limits in place (on
stubs) well before the Flag Day, is a Bad Idea, because it removes the
incentives to participate in Flag Day itself.

On the other hand, I think it would be possibly a good idea to roll out
limited user experimentation of unlimited stub chain lengths, to get the
experiences (and data) regarding user experience, and to get implementation
experience and debugging done, prior to Flag Day.

Post Flag Day, turning it on universally, would then be reasonable to do,
and IMNSHO, this would be the right way to approach it.


>
> 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.
>
>>
>
I'm not disagreeing with the argument on the "should", but that is very
different from anything related to specifications, standards, and "must".

In particular, you need to be REALLY careful, that this can (and in many
cases will) involve different departments in larger organizations, e.g. the
hosting vs DNS, possibly CA, perhaps Load Balancer, and even other groups
responsible for domain purchasing etc.

While those might be coordinated, they might not be, or might be only
vaguely/loosely coordinated, and may not involve ongoing coordination.

There is a huge difference between "best practices" and "mandatory to
implement", and I am afraid you're unintentionally conflating the two.

I.e. Arguments becoming "less valid" is not the same as "this is not a
valid argument", and without it being the latter, it's pretty much
necessary to stomp on this line of argument.

Sorry, and I wish it wasn't the case, but let's face it, DNS is pretty much
a very messy thing when you start allowing client-side rewriting (CNAME)
and then expand it.

Brian