Dear Mark, (CC'ing jab...@strandkip.nl as a context for a follow up reply I will send out soon.)
Thank you for your thoughtful feedback. You make excellent technical points regarding the DNS protocol itself, and you are absolutely correct that when narrowing our focus to DNS server software compliant with RFC 1034/1035 and RFC 3597, adding new record types is indeed well-supported. I should clarify that our draft addresses challenges with the DNS ecosystem as a whole rather than just the core DNS server software. The practical adoption barriers we've encountered include: 1. Domain management interfaces (GoDaddy, Google Domains, Route 53, etc.) that only expose predefined record types in their UIs and APIs, with no option to input records by numeric type 2. DNS control panels and management software that lack support for entering arbitrary record types, even when the underlying nameservers would handle them correctly 3. Public DNS resolvers and CDN providers that require special processes to flush or update their caches for non-standard record types 4. Content management systems and web hosting platforms with DNS management features that only support common record types While filing "bugs" against these systems demanding all of them to change is theoretically possible, the reality is that getting widespread changes implemented across dozens of providers presents significant practical challenges and timeline uncertainties if at all feasible. Our prefixed TXT record approach aims to provide a practical transition path that works with the ecosystem as it exists today, while encouraging migration to proper record types as support becomes more widespread. This mirrors successful approaches in other standards bodies, like the W3C vendor prefixes, which helped bridge similar adoption gaps. We appreciate your expertise and would welcome any suggestions on how we might improve this approach or better articulate the ecosystem challenges we're addressing. Best regards, 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 4:15 PM Mark Andrews <ma...@isc.org> wrote: > > > 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
