On Thu, Mar 6, 2025 at 1:25 PM Victor Zhou <zzn=40namefi...@dmarc.ietf.org> wrote:
> Thank you very much Tommy for the feedback! Answered inline > > Victor, CEO/Founder of Namefi <http://namefi.io> (D3Serve Labs Inc.) > Building digital trust and tokenizing domain names for trading, DeFi and > future Internet. https://namefi.io > > > On Thu, Mar 6, 2025 at 9:46 AM <tojens.i...@gmail.com> wrote: > >> Hey Zainan (or do you prefer Victor on-list?), >> >> >> >> I understand the desire to make deployment of new RR types easier, but >> I’m not convinced this will actually help in practice. Will adopters of new >> RR types **want** to take a dependency on TXT record queries knowing >> they will want to deprecate it later? There’s nothing more permanent than a >> temporary solution, after all. >> > > Haha yes for many cases, we all developers and we know that! > > However, there are cases when the industry moves, we create a life cycle > of adoptions (and deprecations). > Examples like > - credit cards gradually introduced strips, chips and then dropped > the embossed, probably soon to drop strips. > - W3c vendor prefix > <https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Prefix> so that > different browser vendors can begin building features and gaining > adoptions. At the end of the adoption cycle, deprecations started to kick > in and now most CSS3 are natively supported. > > Therefore I am still optimistic! > > >> This also removes some pressure on server operators to move to the new RR >> type (“you’re not blocked, so we will get to it eventually”) and seems like >> it would encourage a new ecosystem where we simply move TXT for all new use >> cases. >> > > Yes, however there are some natural benefits of having their own new RR > type such as a few extra chars of space, better chunking or sequencing > support, better query support and DNSSEC support compared to TXT. The same > happens to the W3C vendor prefix and ultimately everyone moved on. > > Having a TXT prefix enables a "progressive evolution" rather than > requiring a "decisive revolution" for introducing new RR and other DNSOP > features. > > > >> >> >> Setting that aside, for the mechanism: the chunking mechanism does not >> account for the possibility of multiple instances of an RR type in the same >> zone. >> > > Yeah, agree with you on this consideration. There is a tradeoff to be made > about how to better support multiple instances. One thing I am unsure is > whether chunking and multi-instance should be within this RFC scope or not. > The challenge seems to come up in other RFCs too, such as the RFC 6376 > (DKIM Signatures), RFC 4408 (SPF Records): since TXT has no ordering > guarantee. > > Should we handle it in this RFC or have a separate RFC to discuss how to > handle long TXT records? > EDNS(0) seemed to un/intentionally leave longer TXT chunk recovery out of > its scope. > > With cryptography, it seems to be coming up sooner. > > > >> Also, the chunking indicator is ambiguous by being indeterminately >> present: what if the payload of the new RR type wants to start with >> something that looks like 1/2? I would recommend that you (1) make the >> chunking indicator mandatory, even if it’s 1/1, and (2) add an instance >> identifier that would disambiguate different records (example: a:1/1, >> b:1/2, b:2/2). >> > > I think this is a great suggestion. I will update the RFC as one of the > decision options. > > >> >> Thanks, >> >> Tommy >> >> >> >> *From:* Victor Zhou <zzn=40namefi...@dmarc.ietf.org> >> *Sent:* Thursday, March 6, 2025 6:10 AM >> *To:* dnsop@ietf.org >> *Subject:* [EXTERNAL] [DNSOP] I-D Action: draft-zzn-dns-new-rr-00 - >> Prefixed TXT Records as Transition Mechanism for New RR Types >> >> >> >> You don't often get email from zzn=40namefi...@dmarc.ietf.org. Learn why >> this is important <https://aka.ms/LearnAboutSenderIdentification> >> >> Dear DNSOP Working Group, >> >> I am pleased to submit the Internet-Draft "Prefixed TXT Records as >> Transition Mechanism for New RR Types" (draft-zzn-dns-new-rr-00) for your >> consideration and feedback. >> >> >> >> This draft addresses a long-standing adoption challenge in the DNS >> ecosystem: the "chicken and egg" problem encountered when introducing new >> Resource Record (RR) types. New RR types often face slow adoption because >> implementers hesitate to use them until widely supported, while DNS >> providers hesitate to support them until widely used. >> >> The approach proposed in this draft is a transition mechanism using >> prefixed TXT records (with an "RFC<number>" prefix pattern inspired by >> W3C's vendor prefix approach in CSS) to enable immediate deployment of new >> RR type functionality before universal support is available. This mechanism >> provides a clear migration path to the standardized RR type while ensuring >> continuous functionality during the adoption phase. >> >> Key aspects of the proposal include: >> - A standardized format for prefixed TXT records >> - A defined four-phase transition process >> - Clear processing rules and priority guidelines >> - A chunking mechanism for larger data sets >> - Security considerations specific to this approach >> >> This draft is relevant to DNSOP as it addresses operational concerns with >> DNS protocol extensions and provides a practical solution that could >> accelerate innovation in the DNS ecosystem while maintaining backward >> compatibility. >> >> I would greatly appreciate your feedback on: >> 1. The overall approach and whether it addresses a real need >> 2. The technical details of the prefixed format and chunking mechanism >> 3. Additional security considerations that may need to be addressed >> 4. Potential impact on DNS operations and zone management >> 5. Whether this should be considered for advancement on the standards >> track >> >> Thank you for your time and consideration. I look forward to your >> comments and discussions. >> >> Since it's datatracker closing window before IETF-122, a version is >> published on >> https://github.com/xinbenlv/rfc-drafts/blob/main/draft-zzn-dns-new-rr-00.txt >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fxinbenlv%2Frfc-drafts%2Fblob%2Fmain%2Fdraft-zzn-dns-new-rr-00.txt&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Cbd60ab7ee8ed457908d008dd5cb903be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638768671906933701%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TSS%2FcDV80rZlGrawriHSp%2FgEPDUODY0poaPmIH0BZ9Y%3D&reserved=0>, >> will submit once the window opens on Mar 15 or earlier if facilitated by >> chair/admin of the WG >> >> Sincerely, >> Zainan (Victor) Zhou >> z...@namefi.io >> >> >> > > We already have a problem with too many TXT records with the same name used for different purposes. SPF, various validations, and who knows what else are all at the same name. Could we do instead: _RFCxxxx.domain.name IN TXT "<data>" That reduces the packet size and the amount of records that the application has to process and discard, since it will only ask for its own records. -- Bob Harold
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
