On Fri, Dec 27, 2019 at 10:25 AM Eric Orth <ericorth= 40google....@dmarc.ietf.org> 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 chains of > alias-form SVCB records that they will follow. > 3) Stub resolvers SHOULD follow at least one alias-form HTTPSSVC record > before enforcing chain limits. > 4) Recursive resolvers SHOULD follow at least (8?) alias-form > HTTPSSVC records before enforcing chain limits. > > Point (1) is an extension/clarification of the similar rule for CNAME in > RFC1034. I think SVCB would work a lot better if everybody just always > aliases to the final server whenever possible and reasonable. > This element of 1034 has never been observed by implementers or operators. If you REALLY need this clarified, maybe a 1034-bis that removes this rule on CNAMEs, would make the documentation on DNS consistent with deployed reality. If you insist on SVCB mirroring 1034, please be prepared for a lot of pushback, up to and including such a -bis document... SVCB might work better if everyone does what you ask, but the underlying reality is that that is not always possible (at all), where "not always" means "anywhere that single-vendor vertical integration is not occurring". There are currently artificial barriers to interoperation, which result in several (more than 3?) instance of vertical integration, each of which has 20% (in many cases, much less) of the total domain name space. This limitation on SVCB prevents real-world use of SVCB for inter-provider (hybrid, redundant, whatever) usage. I'd like to see an eventual deployment scenario where any domain can use SVCB for any appropriate use case, and where resolvers do all the SVCB heavy lifting. We can't get there if we can't get beyond the vertical integration limitation, which Point (1) necessarily prohibits for 99% of existing actual deployed apex "cname" usage, which is likely to be the earliest and biggest use case of alias-form SVCB. (Specifically, adding SVCB aliases to SVCB alias or CNAME records within vertical integration environments.) As for Point (3), I don't think we are yet at a consensus of which value of "N" (e.g. "one") is reasonable, given the functional requirement for deployment in the real world. Brian > > Point (2) essentially serves as a warning to not assume long chains will > always be followed. The allowed length may vary, but many operators are > going to impose a limit at some point out of practicality. > > Points (3) and (4) set the expectation of reasonable minimum limits for > everything to work well. Recursives are given a higher limit because, as > stated in this thread, it is very reasonable for those operators to support > such higher limits. Stubs are given a lower limit because it is less > reasonable for them to support the long chains, but they are still expected > to follow at least one alias because that is the minimum to support the > obvious usecase of allowing https://example.com/ aliasing. Both these > points only apply to HTTPSSVC, and leave SVCB less defined, as what is > reasonable behavior may be more varied in non-HTTPS cases. > > On Fri, Dec 27, 2019 at 12:54 PM 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. >> 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. >> >> 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. >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
