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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
