My point was not really related to EDNS. My main point is that the last time someone attempted to write a new format for DNS messages in DNSOP, it ended up in the Independent Stream, because standardizing these things isn't easy. There are a lot of opinions and considerations.
One of the key considerations in that discussion, and also in this one, is the need to avoid ossification by moving a portion of the DNS ecosystem to a representation that cannot evolve in the same way as standard DNS. This might explain why RFC 8427 (which tries hard to be isomorphic to the DNS message format) is totally different from the most widely used DNS JSON format (https://developers.google.com/speed/public-dns/docs/doh/json#api-specification). You might solve this by showing that your representation really is isomorphic to standard DNS, both now and for any reasonable future extensions. Alternatively, you might want to specify a very restrictive "CoAP DNS lookup API", emphasizing that this is not a fully-featured DNS format. Either way, I think the work will need extensive discussion and review here in DNSOP. --Ben ________________________________ From: DNSOP <[email protected]> on behalf of Martine Sophie Lenders <[email protected]> Sent: Friday, November 10, 2023 3:42 PM To: dnsop <[email protected]> Cc: [email protected] <[email protected]> Subject: [DNSOP] DNS in Constrained Network Scenarios Hi! This morning I presented two drafts in DNSOP: - https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/, DNS over CoAP (currently discussed in core WG), and - https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/, CBOR of DNS Messages (currently discussed in cbor WG) We would be happy about your input on both of these drafts. Ben raised the point during the meeting that a new data format, such as CBOR of DNS has issues and referenced the JSON document presented before. As far as I understood, the problem there was that there was just no representation of EDNS(0) records specified. This is not an issue with the CBOR format because of the following reasons: (a) there is a dedicated format for EDNS records specified. (b) if a record is, for any reason, not representable in CBOR, one can always fallback to the “classic” binary format of the resource record. This means, the format as specified in RFC 1035, section 3.2.1, is carried it as a byte string within the CBOR object (which itself is in a binary format), see Section 3.2 of the CBOR draft. So in that sense, CBOR of DNS is future-proof as long as such new resource records are parsable by a classic DNS parser as well. For a quick introduction into the message format, I invite you to take a look at the beginning (slides 4-7) of my talk I gave in the CBOR WG. I did not include these details in my DNSOP talk in the interest of time: https://youtu.be/R1l8SBjnjQg?t=1599 (slides: https://datatracker.ietf.org/meeting/118/materials/slides-118-cbor-draft-lenders-dns-cbor-01.pdf) Best Martine
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
