Hi Ben, hi Jerry, On 10.11.23 22:55, Ben Schwartz wrote:
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 <https://developers.google.com/speed/public-dns/docs/doh/json#api-specification>).
The advantage of the CBOR-Format here is, I think, that we can and do represent fields still in their binary or numerical format (e.g., flags or rdata). So we might prevent ossification already: On one hand we do not have very specific maps (the CBOR equivalent to JSON objects) in the first place (like in most JSON formats I have seen), just arrays. On the other, we allow for as much as necessary to be in the original format.
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.
Intuitively, I would say it is isomorphic. We'll try to find a formal way to prove this.
Either way, I think the work will need extensive discussion and review here in DNSOP.
Agreed! On 13.11.23 09:44, Jerry Lundström wrote: > On 11/10/23 22:55, Ben Schwartz wrote: >> Alternatively, you might want to specify a very restrictive "CoAP DNS >> lookup API", emphasizing that this is not a fully-featured DNS format. > > +1 to this! > > I admit I don't know much about CoAP but by the description during the > presentation, being constrained in all it's ways, and that CoAP devices > will likely never be able to process things like DNSSEC, a lookup > service seems much more fitting.The hope is, that even protocols like DoH might benefit from the small message footprint.
Regarding DNSSEC: We discussed this in the context of our research project already, and there exists a rough, private draft for an extension for the CBOR format. We still need to look into more detail if and how sensible it is to get this into the mainline format.
Best Martine
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
