On Mon, Dec 23, 2019 at 12:22 PM Eric Orth <ericorth= 40google....@dmarc.ietf.org> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop