Moin! On 21 May 2021, at 20:16, Brian Dickson wrote: > I think the handling of presentation formats and wire formats leaves much > to be desired. As others said the wire format is a pretty standard TLV format, so I don’t think there is a change needed as this sort of format is well understood. I’m also confident that zone file presentation can be sorted out for regular uses and we always have the generic \nnn escaping for the more complicated ones.
> However, the handling of future extensions is not (IMHO) currently usable > via the existing proposed mechanism. > > The discussion about "what if ECN needed to be added later" got me thinking > about the issue. > > I think there is a need for something similar to RFC3597, except for fields > in a record rather than a BLOB for the record itself. > RFC3597 is fine for an RRTYPE with only one RDATA element/structure, but > not for complex RRs. RFC3597 just works fine with HTTPS. Most people have been using it for some time now, unless they have recursor already supports HTTPS/SVCB. IMHO HTTPS has shown that RFC3597 works today as there were only minor effects on rolling out a new resource record. I think Google did an additional test with an unregistered RRType and came to the same conclusion, but I don’t have the details at hand. > So, this problem on sub-field encodings has arisen from ignoring RFC5507 > (regardless of why it has been ignored). The only mention of that is in comparison to TXT records people used for e.g SPF and other things. The specific advise there is only if your record size is so big that it exceeds general DNS packet size make it a pointer instead of stuffing it in the resource record. The generic advice of RFC5507 is to create a real resource record type instead of using TXT, and IMHO this draft follows this advice (both the RR and size recommendations). So long -Ralf ——- Ralf Weber _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
