Hey Zainan (or do you prefer Victor on-list?),

 

I understand the desire to make deployment of new RR types easier, but I'm
not convinced this will actually help in practice. Will adopters of new RR
types *want* to take a dependency on TXT record queries knowing they will
want to deprecate it later? There's nothing more permanent than a temporary
solution, after all. This also removes some pressure on server operators to
move to the new RR type ("you're not blocked, so we will get to it
eventually") and seems like it would encourage a new ecosystem where we
simply move TXT for all new use cases.

 

Setting that aside, for the mechanism: the chunking mechanism does not
account for the possibility of multiple instances of an RR type in the same
zone. Also, the chunking indicator is ambiguous by being indeterminately
present: what if the payload of the new RR type wants to start with
something that looks like 1/2? I would recommend that you (1) make the
chunking indicator mandatory, even if it's 1/1, and (2) add an instance
identifier that would disambiguate different records (example: a:1/1, b:1/2,
b:2/2). 

 

Thanks,

Tommy

 

From: Victor Zhou <zzn=40namefi...@dmarc.ietf.org> 
Sent: Thursday, March 6, 2025 6:10 AM
To: dnsop@ietf.org
Subject: [EXTERNAL] [DNSOP] I-D Action: draft-zzn-dns-new-rr-00 - Prefixed
TXT Records as Transition Mechanism for New RR Types

 

        
You don't often get email from zzn=40namefi...@dmarc.ietf.org
<mailto:zzn=40namefi...@dmarc.ietf.org> . Learn why this is important
<https://aka.ms/LearnAboutSenderIdentification>  

        

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
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Fxinbenlv%2Frfc-drafts%2Fblob%2Fmain%2Fdraft-zzn-dns-new-rr-00.txt&data=0
5%7C02%7CJensen.Thomas%40microsoft.com%7Cbd60ab7ee8ed457908d008dd5cb903be%7C
72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638768671906933701%7CUnknown%7CTW
FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj
oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TSS%2FcDV80rZlGrawriHSp%2FgEPD
UODY0poaPmIH0BZ9Y%3D&reserved=0> , 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 <mailto:z...@namefi.io> 

 

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to