top-reply clarification:
Chain-length and chain processing should not actually require more than 2
SVCB lookups, and those should only be in direct succession.
Chains involving CNAME are already handled by resolvers, so the incremental
work done by stubs would be limited to 1 or 2 iterations of the SVCB
components.
The supported chains should be, at most, CNAME* (zero or more, no limit) ->
SVCB-alias -> {optional second SVCB-alias -> any other type | non-alias
SVCB} with a restriction that if the "any other type" happens to be a CNAME
or DNAME, that no further SVCB be expected or allowed.
Hopefully this clarifies my comments about chain length and the incremental
addition of SVCB to the chains.
I think "1 or 2" is a reasonable limit to impose *on SVCB* within chains,
without further restrictions on any other chaining that might occur during
resolution (all of which can already be handled by resolvers).
Brian
On Fri, Dec 27, 2019 at 12:05 PM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:
>
>
> On Fri, Dec 27, 2019 at 9:55 AM Eric Orth <erico...@google.com> wrote:
>
>>
>>
>> On Mon, Dec 23, 2019 at 3:57 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> 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
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
