On 12/23/19 9:22 PM, Eric Orth wrote:
> 2) Any chain limiting enforcement only applies to stubs following
> chains, not recursives.
>
> Recursives are already following CNAMEs without a standardized limit.
> [...]
(I'm a bit late, I'm sorry.) Recursives *in practice* seem quite
limited. Unbound
On Friday, 27 December 2019 18:25:29 UTC Eric Orth wrote:
> I propose we add the following 4 statements to the spec:
> 1) Alias-form SVCB records SHOULD NOT delegate to names with any form of
> alias record such as alias-form SVCB or CNAME.
> 2) Clients receiving SVCB records MAY limit the length o
In article
you write:
>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.
Hi. I'm a guy in a hard to pronounce country somewhere in the
southern hemisphere. I just set up a little web site at my loca
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 th
On Fri, Dec 27, 2019 at 10:25 AM Eric Orth wrote:
> I propose we add the following 4 statements to the spec:
> 1) Alias-form SVCB records SHOULD NOT delegate to names with any form of
> alias record such as alias-form SVCB or CNAME.
> 2) Clients receiving SVCB records MAY limit the length of chai
On Fri, Dec 27, 2019 at 9:55 AM Eric Orth 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
>
Eric Orth wrote:
CNAMEs already exist without a standardized limit. Good or bad, too late
to change that without breaking things.
According to rfc1034:
Domain names in RRs which point at another name should
always point at the primary name and not the alias.
CNAME chain is p
On Monday, 23 December 2019 20:22:01 UTC Eric Orth 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 breaki
On Mon, Dec 23, 2019 at 12:22 PM Eric Orth 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 thing
On Mon, Dec 9, 2019 at 10:03 AM Ben Schwartz wrote:
> Changed title to reflect this thread's topic.
>
>
> SVCB is fully "mixable" with CNAME, so there's no need to use SVCB's
> AliasForm when CNAME will do. CNAME chains are followed at every step
> of SVCB resolution. AliasForm's only significa
we should not limit the alias chain length across zones (other than for
loop protection which should be standardized) because there is no
administrative consistency across zones - its just a pointer. So the alias
you're pointing at now might become an alias itself later totally out of
your control.
11 matches
Mail list logo
