Re: [DNSOP] SVCB chain lengths
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 has limit of 10, for BIND it's less than 20, I think. OK, for SVCB the suggested limits so far were lower than 10 (or unspecified/unlimited). This is one of the cases where it seems quite difficult to agree to standardize a particular number, even though "unlimited" doesn't make any sense, and we end up in a fuzzy state where no particular guarantees get standardized (or followed). --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB chain lengths
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 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. > > [explaination] sgtm. +1. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB chain lengths
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 local ISP. They handle the DNS and said something about CNAME and SVCB and the guy complained that the national domain registry never answers the phone and it takes a month to register new 2LD names. When my mother looks at my web site on her Android phone, what will she see? Signed, Wondering ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB chain lengths
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 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 o
Re: [DNSOP] SVCB chain lengths
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 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 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 muc
Re: [DNSOP] SVCB chain lengths
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 >>> 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 myo
Re: [DNSOP] SVCB chain lengths
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 prohibited, though, according to the robustness principle, the rfc says chains should be followed. > aliasing apex names, are new and thus currently limited to zero. Seems to be a reasonable restriction. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB chain lengths
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 breaking things. ... CNAME loops must be detected, so whatever unstandardized limit is chosen, must be both greater than one, and finite. i agree with your associated SVCB reasoning, but we should be clear here that there are standardized boundaries for CNAME chain lengths, even if there is no specific standardized limit for same. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB chain lengths
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 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 st
Re: [DNSOP] SVCB chain lengths
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 significant* advantage is that > it can be used at a zone apex. > > AliasForm also has a serious downside compared to CNAME: clients whose > recursive resolver is not SVCB-aware will have to follow the alias > themselves, resulting in significantly slower resolution than a CNAME. > For this reason, domain owners should avoid using AliasForm if CNAME > will suffice. > > If zone owners are testing/benchmarking with recursive resolvers that > are SVCB-aware or have very low latency (as seems likely), they may > not expect this penalty, and there is no way for them to detect or > measure it after deployment. I have heard this called a "performance > footgun". Hopefully this explains why some developers have asked to > limit the use of AliasForm. > > So, there is historical experience with other deployments of tech, that leads to me suggest we not take this approach.* The gist of the issue is, whether we can consider this RRTYPE to be a first class type. My position is, if this is something adopted, it MUST be a first-class type. I recognize that this may seem a hard line to take, but the alternative approaches all lead to delayed uptake on the resolver side, which can lead to an eventual failure of the type itself.* While there is definitely a potential down-side to early use of the new type, there may be ways of mitigating this, by strongly encouraging upgrades to resolvers to support this type. E.g. this could potentially be added to something like the DNS "Flag Day" for an upcoming year, ideally if we can get this all locked down and published, in 2020's flag day. Or, pushed as a security thing with a CVE (real or not). The example I like to use for adding something that by itself might not have been compelling, where having it has been very helpful in retrospect was having DNAME being required as part of DNSSEC and thus implicitly required for EDNS support. Making AliasForm a first class type, means making it exactly the same semantically as CNAME (and DNAME, it is worth noting), with no restrictions on either location or chain length (beyond loop checking) from DAY ONE, not at some unspecified later date. The issues of performance SHOULD (IMNSHO) be directed where they really belong, on the recursive resolvers, not the authoritative servers (via limits on where and how deep chains can occur). I'm happy to elaborate on any of this to educate anyone not intimately familiar with Flag Day, DNAME, EDNS, or other DNS-history-specific things referenced here -- contact me offline at your convenience. Brian * SPF; anything else that overloaded TXT; DNSSEC validation; EDNS(0); DNS MTU generally; OPT RRTYPE handling of new/unknown TLVs; new/unknown RRTYPEs; etc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB chain lengths
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.. or it might inconsistently do so thanks to
localized/balanced results you don't have any view into. Or, vice-versa,
someone might be pointing an alias at you when you do add an alias record
and you break them suddenly. You can say "don't point at an apex", but the
property of an apex isn't a constant one either - so someone adds a new
apex and breaks everyone that has an alias pointing at them. This is not
centrally coordinated so adding rules that need to be socially tracked
beyond the configuration you actually control is an un-necessarily fragile
system.
I also don't think a value of 1 achieves performance goals because when it
works it just replaces aliases with cnames and they perform the same. Plus,
it creates situations where it doesn't work - and that definitely performs
worse :)
As for use cases, I don't think there is any reason to think an apex wants
fewer redirections than non-apex. We all know that 0 is a real problem, and
that non-apex can have quite a few. redirections are a performance problem,
but substituting cname pointers for alias pointers doesn't improve that.
The loop protection text should indicate that the length of the chain is
inclusive of both kinds of indirections.
-P
On Mon, Dec 9, 2019 at 1:03 PM Ben Schwartz wrote:
> Changed title to reflect this thread's topic.
>
> I wanted to add some background on this question (which is also
> tracked on Github:
> https://github.com/MikeBishop/dns-alt-svc/issues/57).
>
> SVCB supports two forms, one of which ("AliasForm") acts somewhat like
> a CNAME, and in principle could be chained indefinitely. The current
> draft says
>
> > Chains of consecutive SVCB and CNAME records SHOULD be limited to (8?)
> prior to reaching terminal address records.
>
> This discussion is about finding a good replacement for this
> placeholder language. (IMHO the placeholder is also problematic
> because it arguably alters requirements for CNAME handling.)
>
> 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 significant* advantage is that
> it can be used at a zone apex.
>
> AliasForm also has a serious downside compared to CNAME: clients whose
> recursive resolver is not SVCB-aware will have to follow the alias
> themselves, resulting in significantly slower resolution than a CNAME.
> For this reason, domain owners should avoid using AliasForm if CNAME
> will suffice.
>
> If zone owners are testing/benchmarking with recursive resolvers that
> are SVCB-aware or have very low latency (as seems likely), they may
> not expect this penalty, and there is no way for them to detect or
> measure it after deployment. I have heard this called a "performance
> footgun". Hopefully this explains why some developers have asked to
> limit the use of AliasForm.
>
> Currently (pre-SVCB), the number of apex names that can be present in
> a chain is zero (excluding the final name). The question at hand is:
> should we increase this limit to 1? 2? 8? Unspecified? We have a
> clear use case for 1 (aliasing https://example.com/), but I have yet
> to hear of a use case that needs a limit higher than 1.
>
> There are also several other possible ways to discourage unnecessary
> uses of AliasForm. For example, we could:
> - make it possible for zone owners to tell whether their clients are
> using an SVCB-aware recursive, by making clients' alias chasing
> behavior different from recursives'
> - extend the W3C Resource Timing API (at the W3C) to indicate when
> multiple DNS queries were required
> - ask SVCB-aware recursives to SERVFAIL on AliasForm records that are
> not at an apex (excluding _prefixed labels)
>
> --Ben
>
> *For HTTPSSVC (but not SVCB), another difference is that CNAME would
> affect all protocols, whereas AliasForm only affects HTTP connections.
> ___
> 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
