Re: [DNSOP] SVCB chain lengths

2020-01-07 Thread Vladimír Čunát
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

Re: [DNSOP] SVCB chain lengths

2019-12-27 Thread Paul Vixie
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

Re: [DNSOP] SVCB chain lengths

2019-12-27 Thread John Levine
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

Re: [DNSOP] SVCB chain lengths

2019-12-27 Thread Brian Dickson
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

Re: [DNSOP] SVCB chain lengths

2019-12-27 Thread Brian Dickson
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

Re: [DNSOP] SVCB chain lengths

2019-12-27 Thread Brian Dickson
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

Re: [DNSOP] SVCB chain lengths

2019-12-23 Thread Masataka Ohta
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

Re: [DNSOP] SVCB chain lengths

2019-12-23 Thread Paul Vixie
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

Re: [DNSOP] SVCB chain lengths

2019-12-23 Thread Brian Dickson
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

Re: [DNSOP] SVCB chain lengths

2019-12-09 Thread Brian Dickson
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

Re: [DNSOP] SVCB chain lengths

2019-12-09 Thread Patrick McManus
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