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
