> On 7 Mar 2025, at 10:07, Victor Zhou <z...@namefi.io> wrote: > > Thanks Mark. > > Our intention was not to claim it's hard to add a new RR type. it is not hard > to "add" it. It's hard to gain consensus without showing adoption first.
Well that’s what your introduction claimed. 1. Introduction The DNS protocol [RFC1035] has a well-established process for introducing new Resource Record (RR) types through the IANA registry. However, the deployment of new RR types faces significant practical challenges: 1. DNS software must be updated to recognize and handle the new RR type 2. DNS service providers must update their management interfaces 3. Authoritative server operators must deploy updated software 4. Content management systems and domain control panels must be updated 5. Recursive resolvers must properly handle the new RR type These challenges create a "chicken and egg" problem: implementers hesitate to use new RR types until they are widely supported, while DNS providers hesitate to support RR types until they are widely used. This document specifies a transition mechanism using prefixed TXT records to enable immediate deployment of new RR type functionality before universal support is available, while providing a clear migration path to the standardized RR type. > > It's not hard to declare "I" (unilaterally) am going to start treating RR > Type = N as a new type and the client I develop will treat RR Type = N that > way. > 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. You write a specification that specifies the type. I’ve done that a couple of times. You get IANA to allocate a type code. You use it. Whether you get back a TXT record or a opaque blob your application is going to have to decode it. If you want to work on refining the type code then use a type code from 65280-65534 temporarily. Change the typecode whenever you change the wire format so you don’t break clients using the old wire format. I did this with DLV when developing the code to support it. I do this with all new type codes while they are unstable. Once they are assigned a type code I update the code to use the assigned type code and merge the code into the released code. I do similar things while developing EDNS code points. Add words like “For this draft we will use TYPE65289 for testing purposes.” to your drafts. What I’ve see happen too often is people going to IANA too early and then having to go back and get a new type code or try to change an existing type code. As a nameserver developer (BIND) I never want to have to change the code to support an allocated type code once it is written sans fixing bugs. Code that is being used for testing I expect to have to change and possibly throw away. BIND is designed to allow you to add new type easily. Many people have done it in the past. > W3C vendor prefix is a good example. Every browser can declare their way of > adding new CSS tricks but it's hard to get website builders to adopt them > individually, so they come up with a vendor prefix and ultimately use them to > adopt new CSS attributes. > > > Victor, CEO/Founder of Namefi (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 2:52 PM Mark Andrews <ma...@isc.org> wrote: > > Please stop perpetuating the myth that it is hard to add new record types. > It isn’t. > > Nameservers support RFC 3597 Handling of Unknown DNS Resource Record (RR) > Types so there > should be NO nameservers after 20+ years that don’t support it. Nameservers > where supposed > to treat unknown types as opaque data before this was published. This > allowed recursive > servers to lookup and cache unknown types. The hard part was the > authoritative servers > that needed to be upgraded before you could use a new type. This addressed > that issue. > > Resolver code has ALWAYS been required to support looking up unknown type > codes. If your > resolver library doesn’t support that it is BROKEN. File a bug report. I > can use resolver > code from BSD 4.2 and lookup every type that has ever been specified. That > is 40 year old > code now. > > If your DNS provider doesn’t support UNKNOWN TYPES move to one that does. > There is no technical > reason not to support UNKNOWN TYPES. They may try to feed you a line of > bovine excrement as to > why they can’t support it but don’t fall for it. It’s their job to support > ALL types. They work > for you! > > When specifying a new types show examples using UNKNOWN TYPE FORMAT as well > as whatever > display format is most appropriate for the type. More recent type > specifications have > done this. > > These are the same A record. > > example.com TYPE1 \# 4 0a000001 > example.com A 10.0.0.1 > > Mark > > > On 7 Mar 2025, at 01:10, Victor Zhou <zzn=40namefi...@dmarc.ietf.org> wrote: > > > > 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, > > 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 > > > > _______________________________________________ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
