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.
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. 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 <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 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 > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
