Dear Ray,Thank you for your feedback as a member of the RR Expert Review Panel. I sincerely value your expertise and perspective on our proposal.I completely agree with your point that applying for a new RR type is "often a very quick process." The technical process of defining and obtaining a new RR type is indeed straightforward.However, while defining a new RR type may be quick, achieving widespread implementation and adoption presents a different set of challenges. The history of TLSA (type 52) for DANE illustrates this journey:
- Though technically sound and RFC-standardized since 2012, TLSA still has room to grow to reach the adoption it originally anticipated - Many domain registrars and DNS hosting providers are still working toward exposing these specialized RR types in their management interfaces - This lack of universal support has hindered opportunities for DANE, with HTTPS certificate distribution ultimately developing through alternative channels like Certificate Authorities The SPF evolution might offer some instructive lessons in this regard: 1. SPF began with a dedicated RR type (99) alongside TXT records 2. Despite large adoption of SPF as a technology, the ecosystem didn't seem to show strong favor for the new RR type over the TXT fallback 3. RFC 7208 (2014) ultimately acknowledged this reality by deprecating the SPF RR type I recognize that dedicated RR types often provide superior performance and efficiency compared to TXT records - these technical advantages can become powerful driving factors for eventual adoption. Our proposal isn't intended to permanently favor TXT records, but to create a bridge that works within today's implementation constraints while enabling immediate adoption. TXT records allow people to begin using new functionality today in the ecosystem as it exists, while establishing a clear path to migrate to dedicated RR types as their benefits become apparent and accessible.I would be grateful for your guidance on how we might better balance technical rigor with practical adoption challenges in our approach.Respectfully,Victor Zhou ... [DNSOP] Re: I-D Action: draft-zzn-dns-new-rr-00 - Prefixed TXT Records as Transition Mechanism for New RR Types Ray Bellis <r...@bellis.me.uk> Fri, 07 March 2025 17:17 UTCShow header <https://mailarchive.ietf.org/arch/msg/dnsop/PAiEZ2xb-1ImjXe-A2Yu_3JdLlM/#> On 07/03/2025 08:37, Joe Abley wrote: > The normal process is that you submit a template and get an > assignment. You don't need to unilaterally declare the existence of > a new RRType. Indeed, and it's often a very quick process. As a member of the RR Expert Review Panel, I am strongly against this proposal primarily because it is far too TXT-specific. The vast majority of the RRs that come to our attention are *not* based on TXT records. Sometimes proposals come to us that are shoe-horned unnecessarily into TXT syntax, when a much more optimal encoding with a dedicated RR would be far more appropriate. [I also find the rationale specious, but IMHO that's moot given my main concern]. Ray Indeed, and it's often a very quick process. As a member of the RR Expert Review Panel, I am strongly against this proposal primarily because it is far too TXT-specific. The vast majority of the RRs that come to our attention are *not* based on TXT records. Sometimes proposals come to us that are shoe-horned unnecessarily into TXT syntax, when a much more optimal encoding with a dedicated RR would be far more appropriate. [I also find the rationale specious, but IMHO that's moot given my main concern]. Ray
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
