Re: [DNSOP] SVCB chain lengths

[Brian Dickson <[e-mail]>]

On Fri, Dec 27, 2019 at 9:55 AM Eric Orth <[e-mail]> wrote:

>
>
> On Mon, Dec 23, 2019 at 3:57 PM Brian Dickson <
> [e-mail]> wrote:
>
>>
>>
>>> 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.)
>>
>
> Chrome is not willing to subject its users to such an easily avoidable
> "pain" simply as an incentive to other operators to help fix the badness.
>

I'm a bit confused by the usage of "other" here. Chrome is not an operator,
unless I am mistaken?

You may be overstating or overestimating the amount of (perceived) "pain",
and the reason I put "pain" in quotes in the first place, it it mostly
boils down to the number of queries to the recursive.

If the recursive is comparatively close to the client, the extra iterations
should add a negligible amount of latency, well below the threshold of
impact to user experience. E.g. a 5ms RTT would add an extra 5ms for a
chain of 2, etc., once the resolver has obtained and cached the additional
elements of the chain.

The worst-case latency is only seen the first time every element of a chain
is resolved. Even though the client (browser) does need to chase the SVCB
component(s), it still does so through its resolver, not directly, and all
the benefits of caching are still reaped.


> As much as users taking a latency hit of following long chains would
> incentivize recursives to follow the chains on their side, requiring long
> chain following would be an even stronger incentive to browsers and other
> stub clients to not support any HTTPSSVC alias following or maybe not
> support standardized HTTPSSVC at all.
>

As was discussed (mostly by me) up-thread, the real-world expectation on
chains should be 2, not 1, as a median value.

The main motivations for ANAME (within DNSOP) which were (gladly) subsumed
by SVCB, were interoperation between different classes of providers, and
multi-vendor operation (for reliability, availability, etc.). Those use
cases typically REQUIRE a minimum of 2 levels of SVCB chaining: 1 for the
internal use within a particular class of provider, plus 1 for the
inter-operator dereference operation.

Limiting this to a chain length of 1 (i.e. requiring SVCB to not point to
another SVCB or CNAME) then turns into a requirement to dynamically update
the target fields of the SVCB or CNAME, a requirement that was the death
knell of the original ANAME spec. ANAME went through a large number of
iterations trying to solve this issue or to limit its impact, and was
determined to be insolvable.

Having the client side do the chain following is the only viable
alternative, which REQUIRES a non-trivial chain length (i.e. > 1) to
preserve this benefit (i.e. requirement).


>
> But I also disagree that all incentive for recursives to follow chains is
> removed if stubs only follow one alias link.  Even following that single
> alias in the stub is going to almost always be a bit slower than if the
> recursive does it.
>

The main issue that you seem to be missing here, is that it isn't about
recursives, it is about the authoritatives who are serving the various
records (CNAME, alias-form SVCB, DNAME, and non-alias-form SVCB). For the
most part, they are not doing so out of laziness or as a design choice; it
is a requirement from the domain owners who are customers of the various
entities.

Placing restrictions on chain length, places restrictions on those entities
in terms of how they can select providers, and even whether multi-provider
options are feasible.

This is harmful to consumers, harmful to competition, and harmful to the
larger Internet's availability and performance.

So, please, let's look at this from the holistic and systemic level, rather
than the myopic perspective of "just the browser".

I'm in favor of encouraging sensible choices and best practices. However,
IMNSHO, those belong in things like BCPs and operator guidance docs, not
hard limits in core standards documents.

Brian