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 <bemasc= 40google....@dmarc.ietf.org> 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
