On Mon, Dec 9, 2019 at 10:03 AM Ben Schwartz <bem...@google.com> 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
