Dear John and Dave, Thank you both for your thoughtful feedback on our draft proposal.
John - Yes, I am aware of RFCs 8552 and 8553 and the IANA registry for DNS Underscore Names that 8552 creates. Our intention is *not* to compete with or replace the underscore naming scheme, but rather to provide a complementary approach specifically focused on progressive adoption of new RR types. Dave - You're right that platform limitations for editing zone contents are a significant obstacle. That is indeed the driving factor among the issues we listed, and I agree we should focus more narrowly on this particular challenge. To address both of your points: 1. The key difference between the TXT methods and the underscore naming approach is the explicit focus on transitioning to proper RR types. While underscore names create a sustainable naming scheme within TXT records, our proposal aims to establish a clear migration path from TXT to dedicated RR types. 2. There are some technical considerations that make TXT records potentially advantageous for progressive adoption compared to underscore leaf nodes: - CNAME compatibility: Underscore domains cannot coexist with CNAME records at the same owner name, limiting flexibility in certain deployment scenarios. - DNSSEC delegation: Underscore nodes may complicate DNSSEC delegation patterns in some deployment models. - UI visibility: Many DNS management interfaces have special handling for underscore domains (sometimes hiding them from default views), while TXT records are universally accessible. 3. Dave, regarding your skepticism about migration - you raise a valid concern. History shows that temporary solutions often become permanent. However, our goal is to design incentives that encourage migration, not just provide another way to overload TXT. This includes clear documentation of the performance and technical advantages of proper RR types once available. I agree that focusing on getting the biggest platforms to support unknown types would be the ideal solution. Perhaps our proposal could be reframed to emphasize this goal more directly, while providing a practical bridge until that broader support materializes. Would either of you have suggestions on how we might better structure this proposal to address the practical adoption challenges while avoiding the pitfalls you've identified? Best regards, Victor Zhou from: John Levine <jo...@taugh.com> to: dnsop@ietf.org cc: z...@namefi.io date: Mar 7, 2025, 4:30 PM subject: Re: [DNSOP] Re: I-D Action: draft-zzn-dns-new-rr-00 - Prefixed TXT Records as Transition Mechanism for New RR Types mailed-by: iecc.com signed-by: taugh.com security: Standard encryption (TLS) Learn more <https://support.google.com/mail?hl=en&p=tls> : Important because previous messages in the conversation were important. It appears that Victor Zhou <z...@namefi.io> said: >flagging this issue. We may consider replace all references to existing >unrelated RFC numbers (RFC7777, 8888, etc.) with clearly hypothetical >placeholders like RFCNNNN, RFCMMMM, RFCOOOO, and RFCPPPP to avoid >any confusion with actual RFCs.... Are you familiar with RFCs 8552 and 8553, and the IANA registry that RFC 8552 created? Not to put too fine a point on it, but your proposal appears to be worse than the existing practice that those two RFCs describe. It would be helpful if you could explain why this is an improvement. Also look at that registry, which contains over sixty existing underscore prefixes, and tell us why if you don't want to create a new RRTYPE, you would not just add another prefix to that registry and use that. R's, John from: Dave Lawrence <t...@dd.org> via <https://support.google.com/mail/answer/1311182?hl=en> ietf.org to: dnsop@ietf.org date: Mar 7, 2025, 3:43 PM subject: [DNSOP] Re: I-D Action: draft-zzn-dns-new-rr-00 - Prefixed TXT Records as Transition Mechanism for New RR Types mailing list: dnsop@ietf.org Filter messages from this mailing list mailed-by: ietf.org signed-by: ietf.org security: Standard encryption (TLS) Learn more <https://support.google.com/mail?hl=en&p=tls> : Important because previous messages in the conversation were important. Victor Zhou writes: > It's extremely hard, however, to show the world that some new RR Type = N has > been used by many services and clients for a specific use case and in a certain > way. That's why we are intending to come up with a way to show early adoption, > begin early adoption, and then migrate. I don't quite understand how your proposed mechanism is an improvement for a way to show early adoption ... except, acknowledging John Levine's point, that current web platforms for editing zone contents continue to be an obstacle for using new types. Do you have something else in mind? That was just one of your five bullet points, and if it's the driving one then it should be focused and the four others, which are largely inaccurate, dropped. Or, we could focus on getting the biggest platforms to allow unknown types. Even if this proposal is pursued, let's not kid ourselves about "and then migrate". It's really just ultimately a means for overlaying multiple uses of TXT indefinitely.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
