additional byte to define the length of the first name component and well as a zero byte at the end
of the name.
With CBOR on the other hand only 1 byte is required to define type and length of the text string up
-until a string length of 23 characters.
-Likewise, if the record data is purely a numerical value, it can be expressed as either an unsigned
-or negative integer.¶
+until a string length of 23 characters.¶
+
There is an argument to be made for more structured formats of other record data representations
+(e.g. MX or SOA), but these usually add more overhead. As such, those record data are to be
+represented as a byte string.¶
This section records the status of known implementations of the protocol
+defined by this specification at the time of posting of this
+Internet-Draft, and is based on a proposal described in
+[RFC7942]. The description of implementations in this
+section is intended to assist the IETF in its decision processes in
+progressing drafts to RFCs. Please note that the listing of any individual
+implementation here does not imply endorsement by the IETF. Furthermore,
+no effort has been spent to verify the information presented here that was
+supplied by IETF contributors. This is not intended as, and must not be
+construed to be, a catalog of available implementations or their features.
+Readers are advised to note that other implementations may exist.¶
+
According to [RFC7942], "this will allow reviewers and
+working groups to assign due consideration to documents that have the
+benefit of running code, which may serve as evidence of valuable
+experimentation and feedback that have made the implemented protocols more
+mature. It is up to the individual working groups to use this information
+as they see fit".¶
The authors of this document provide a decoder/encoder
+implementation of the unpacked format specified in this
+document for the RIOT operating system. It can only encode queries and decode responses.¶
IANA is requested to assign CoAP Content-Format ID for the new DNS message media
+
IANA is requested to assign CoAP Content-Format ID for the new DNS message media
types in the "CoAP Content-Formats"
sub-registry, within the "CoRE Parameters" registry [RFC7252], corresponding the
-"application/dns+cbor" media type specified in Section 6.1:¶
+"application/dns+cbor" media type specified in Section 7.1:¶
Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, , <https://www.rfc-editor.org/rfc/rfc7228>.
+
[RFC7942]
+
+Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/rfc/rfc7942>.
diff --git a/comparison-table/draft-lenders-dns-cbor.txt b/comparison-table/draft-lenders-dns-cbor.txt
index e57dc8f..2d57d81 100644
--- a/comparison-table/draft-lenders-dns-cbor.txt
+++ b/comparison-table/draft-lenders-dns-cbor.txt
@@ -5,12 +5,12 @@
CBOR M. S. Lenders
Internet-Draft TU Dresden
Intended status: Standards Track C. Bormann
-Expires: 15 April 2024 Universität Bremen TZI
+Expires: 16 May 2024 Universität Bremen TZI
T. C. Schmidt
HAW Hamburg
M. Wählisch
TU Dresden & Barkhausen Institut
- 13 October 2023
+ 13 November 2023
A Concise Binary Object Representation (CBOR) of DNS Messages
@@ -53,9 +53,9 @@ Status of This Memo
-Lenders, et al. Expires 15 April 2024 [Page 1]
+Lenders, et al. Expires 16 May 2024 [Page 1]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
Internet-Drafts are draft documents valid for a maximum of six months
@@ -63,7 +63,7 @@ Internet-Draft dns+cbor October 2023
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on 15 April 2024.
+ This Internet-Draft will expire on 16 May 2024.
Copyright Notice
@@ -94,36 +94,40 @@ Table of Contents
4.1. Media Type Negotiation . . . . . . . . . . . . . . . . . 10
4.2. DNS Representation in Packed CBOR . . . . . . . . . . . . 10
4.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 10
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 6.1. Media Type Registration . . . . . . . . . . . . . . . . . 11
- 6.1.1. "application/dns+cbor" . . . . . . . . . . . . . . . 11
- 6.2. CoAP Content-Format Registration . . . . . . . . . . . . 12
- 6.2.1. "application/dns-cbor" . . . . . . . . . . . . . . . 12
- 6.2.2. "application/dns+cbor;packed=1" . . . . . . . . . . . 12
- 6.3. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 12
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
- 7.2. Informative References . . . . . . . . . . . . . . . . . 14
- Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15
-
-
-
-Lenders, et al. Expires 15 April 2024 [Page 2]
+ 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
+ 5.1. Python decoder/encoder . . . . . . . . . . . . . . . . . 11
+ 5.2. Embedded decoder/encoder . . . . . . . . . . . . . . . . 11
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 12
+ 7.1.1. "application/dns+cbor" . . . . . . . . . . . . . . . 12
+ 7.2. CoAP Content-Format Registration . . . . . . . . . . . . 13
+ 7.2.1. "application/dns-cbor" . . . . . . . . . . . . . . . 13
+ 7.2.2. "application/dns+cbor;packed=1" . . . . . . . . . . . 13
+ 7.3. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 13
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
+
+
+
+Lenders, et al. Expires 16 May 2024 [Page 2]
-Internet-Draft dns+cbor October 2023
-
-
- A.1. DNS Queries . . . . . . . . . . . . . . . . . . . . . . . 15
- A.2. DNS Responses . . . . . . . . . . . . . . . . . . . . . . 15
- Appendix B. Comparison to Wire Format . . . . . . . . . . . . . 17
- Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 19
- C.1. Since draft-lenders-dns-cbor-03 . . . . . . . . . . . . . 19
- C.2. Since draft-lenders-dns-cbor-02 . . . . . . . . . . . . . 19
- C.3. Since draft-lenders-dns-cbor-01 . . . . . . . . . . . . . 19
- C.4. Since draft-lenders-dns-cbor-00 . . . . . . . . . . . . . 19
- Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
+Internet-Draft dns+cbor November 2023
+
+
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 15
+ Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16
+ A.1. DNS Queries . . . . . . . . . . . . . . . . . . . . . . . 16
+ A.2. DNS Responses . . . . . . . . . . . . . . . . . . . . . . 17
+ Appendix B. Comparison to Wire Format . . . . . . . . . . . . . 18
+ Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 20
+ C.1. Since draft-lenders-dns-cbor-04 . . . . . . . . . . . . . 20
+ C.2. Since draft-lenders-dns-cbor-03 . . . . . . . . . . . . . 20
+ C.3. Since draft-lenders-dns-cbor-02 . . . . . . . . . . . . . 20
+ C.4. Since draft-lenders-dns-cbor-01 . . . . . . . . . . . . . 20
+ C.5. Since draft-lenders-dns-cbor-00 . . . . . . . . . . . . . 20
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
@@ -161,13 +165,9 @@ Internet-Draft dns+cbor October 2023
-
-
-
-
-Lenders, et al. Expires 15 April 2024 [Page 3]
+Lenders, et al. Expires 16 May 2024 [Page 3]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -221,9 +221,9 @@ Internet-Draft dns+cbor October 2023
-Lenders, et al. Expires 15 April 2024 [Page 4]
+Lenders, et al. Expires 16 May 2024 [Page 4]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
Further special records, e.g., TSIG can be defined in follow-up
@@ -277,22 +277,25 @@ Internet-Draft dns+cbor October 2023
-Lenders, et al. Expires 15 April 2024 [Page 5]
+Lenders, et al. Expires 16 May 2024 [Page 5]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
at the end of the name. With CBOR on the other hand only 1 byte is
required to define type and length of the text string up until a
- string length of 23 characters. Likewise, if the record data is
- purely a numerical value, it can be expressed as either an unsigned
- or negative integer.
+ string length of 23 characters.
+
+ There is an argument to be made for more structured formats of other
+ record data representations (e.g. MX or SOA), but these usually add
+ more overhead. As such, those record data are to be represented as a
+ byte string.
rr = [
? name: domain-name,
ttl: uint,
? type-spec,
- rdata: int / bstr / domain-name,
+ rdata: bstr / domain-name,
]
type-spec = (
record-type: uint,
@@ -327,16 +330,15 @@ Internet-Draft dns+cbor October 2023
extended RCODE MUST not be elided. If the RCODE is not elided the
extended flags MUST not be elided.
- TBD: reverse extended flags to get MSB-defined DO into LSB?
-
-
-Lenders, et al. Expires 15 April 2024 [Page 6]
+Lenders, et al. Expires 16 May 2024 [Page 6]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
+
+ TBD: reverse extended flags to get MSB-defined DO into LSB?
Note that future EDNS versions may require a different format than
the one described above.
@@ -387,11 +389,9 @@ Internet-Draft dns+cbor October 2023
-
-
-Lenders, et al. Expires 15 April 2024 [Page 7]
+Lenders, et al. Expires 16 May 2024 [Page 7]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
This specification assumes that the DNS messages are sent over a
@@ -445,9 +445,9 @@ Internet-Draft dns+cbor October 2023
-Lenders, et al. Expires 15 April 2024 [Page 8]
+Lenders, et al. Expires 16 May 2024 [Page 8]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
3.4. DNS Responses
@@ -501,9 +501,9 @@ Internet-Draft dns+cbor October 2023
-Lenders, et al. Expires 15 April 2024 [Page 9]
+Lenders, et al. Expires 16 May 2024 [Page 9]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
dns-response = [
@@ -547,9 +547,7 @@ Internet-Draft dns+cbor October 2023
compression is applied, is out of scope of this document. Several
potential compression algorithms were evaluated in [TBD].
-5. Security Considerations
- TODO Security
@@ -557,20 +555,88 @@ Internet-Draft dns+cbor October 2023
-Lenders, et al. Expires 15 April 2024 [Page 10]
+
+
+Lenders, et al. Expires 16 May 2024 [Page 10]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
+
+
+5. Implementation Status
+
+ This section records the status of known implementations of the
+ protocol defined by this specification at the time of posting of this
+ Internet-Draft, and is based on a proposal described in [RFC7942].
+ The description of implementations in this section is intended to
+ assist the IETF in its decision processes in progressing drafts to
+ RFCs. Please note that the listing of any individual implementation
+ here does not imply endorsement by the IETF. Furthermore, no effort
+ has been spent to verify the information presented here that was
+ supplied by IETF contributors. This is not intended as, and must not
+ be construed to be, a catalog of available implementations or their
+ features. Readers are advised to note that other implementations may
+ exist.
+
+ According to [RFC7942], "this will allow reviewers and working groups
+ to assign due consideration to documents that have the benefit of
+ running code, which may serve as evidence of valuable experimentation
+ and feedback that have made the implemented protocols more mature.
+ It is up to the individual working groups to use this information as
+ they see fit".
+
+5.1. Python decoder/encoder
+
+ The authors of this document provide a decoder/encoder implementation
+ (https://github.com/netd-tud/cbor4dns) of both the unpacked and
+ packed format specified in this document in Python.
+
+ Level of maturity: prototype
+ Version compability: draft-lenders-dns-cbor-05
-6. IANA Considerations
+ License: MIT
-6.1. Media Type Registration
+ Contact information: Martine Lenders
+
+ Last update of this information: October 2023
+
+5.2. Embedded decoder/encoder
+
+ The authors of this document provide a decoder/encoder implementation
+ (https://github.com/RIOT-OS/RIOT/pull/19989) of the unpacked format
+ specified in this document for the RIOT operating system. It can
+ only encode queries and decode responses.
+
+ Level of maturity: prototype
+
+ Version compability: draft-lenders-dns-cbor-05
+
+
+
+Lenders, et al. Expires 16 May 2024 [Page 11]
+
+Internet-Draft dns+cbor November 2023
+
+
+ License: MIT
+
+ Contact information: Martine Lenders
+
+ Last update of this information: October 2023
+
+6. Security Considerations
+
+ TODO Security
+
+7. IANA Considerations
+
+7.1. Media Type Registration
This document registers a media type for the serialization format of
DNS messages in CBOR. It follows the procedures specified in
[RFC6838].
-6.1.1. "application/dns+cbor"
+7.1.1. "application/dns+cbor"
Type name: application
@@ -583,7 +649,7 @@ Internet-Draft dns+cbor October 2023
Encoding considerations: Must be encoded as using [RFC8949]. See
[TBD-this-spec] for details.
- Security considerations: See Section 5 of this draft
+ Security considerations: See Section 6 of this draft
Interoperability considerations: TBD
@@ -601,6 +667,13 @@ Internet-Draft dns+cbor October 2023
File extension(s): dnsc
+
+
+Lenders, et al. Expires 16 May 2024 [Page 12]
+
+Internet-Draft dns+cbor November 2023
+
+
Macintosh file type code(s): none
Person & email address to contact for further information: Martine S.
@@ -610,14 +683,6 @@ Internet-Draft dns+cbor October 2023
Restrictions on Usage: None?
-
-
-
-Lenders, et al. Expires 15 April 2024 [Page 11]
-
-Internet-Draft dns+cbor October 2023
-
-
Author: Martine S. Lenders m.lenders@fu-berlin.de
(mailto:m.lenders@fu-berlin.de)
@@ -626,14 +691,14 @@ Internet-Draft dns+cbor October 2023
Provisional registrations? No
-6.2. CoAP Content-Format Registration
+7.2. CoAP Content-Format Registration
IANA is requested to assign CoAP Content-Format ID for the new DNS
message media types in the "CoAP Content-Formats" sub-registry,
within the "CoRE Parameters" registry [RFC7252], corresponding the
- "application/dns+cbor" media type specified in Section 6.1:
+ "application/dns+cbor" media type specified in Section 7.1:
-6.2.1. "application/dns-cbor"
+7.2.1. "application/dns-cbor"
Media-Type: application/dns+cbor
@@ -643,7 +708,7 @@ Internet-Draft dns+cbor October 2023
Reference: [TBD-this-spec]
-6.2.2. "application/dns+cbor;packed=1"
+7.2.2. "application/dns+cbor;packed=1"
Media-Type: application/dns+cbor;packed=1
@@ -653,11 +718,18 @@ Internet-Draft dns+cbor October 2023
Reference: [TBD-this-spec]
-6.3. CBOR Tags Registry
+7.3. CBOR Tags Registry
In the registry "CBOR Tags" [IANA.cbor-tags], IANA is requested to
allocate the tags defined in Table 1.
+
+
+Lenders, et al. Expires 16 May 2024 [Page 13]
+
+Internet-Draft dns+cbor November 2023
+
+
+========+===========+===============+========================+
| Tag | Data Item | Semantics | Reference |
+========+===========+===============+========================+
@@ -667,16 +739,9 @@ Internet-Draft dns+cbor October 2023
Table 1: Values for Tag Numbers
+8. References
-
-Lenders, et al. Expires 15 April 2024 [Page 12]
-
-Internet-Draft dns+cbor October 2023
-
-
-7. References
-
-7.1. Normative References
+8.1. Normative References
[I-D.ietf-cbor-packed]
Bormann, C., "Packed CBOR", Work in Progress, Internet-
@@ -712,6 +777,15 @@ Internet-Draft dns+cbor October 2023
RFC 6838, DOI 10.17487/RFC6838, January 2013,
.
+
+
+
+
+Lenders, et al. Expires 16 May 2024 [Page 14]
+
+Internet-Draft dns+cbor November 2023
+
+
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
@@ -722,14 +796,6 @@ Internet-Draft dns+cbor October 2023
DOI 10.17487/RFC7252, June 2014,
.
-
-
-
-Lenders, et al. Expires 15 April 2024 [Page 13]
-
-Internet-Draft dns+cbor October 2023
-
-
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
@@ -745,14 +811,14 @@ Internet-Draft dns+cbor October 2023
DOI 10.17487/RFC8949, December 2020,
.
-7.2. Informative References
+8.2. Informative References
[I-D.ietf-core-dns-over-coap]
Lenders, M. S., Amsüss, C., Gündoğan, C., Schmidt, T. C.,
and M. Wählisch, "DNS over CoAP (DoC)", Work in Progress,
- Internet-Draft, draft-ietf-core-dns-over-coap-03, 10 July
- 2023, .
+ Internet-Draft, draft-ietf-core-dns-over-coap-04, 23
+ October 2023, .
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
@@ -769,6 +835,18 @@ Internet-Draft dns+cbor October 2023
DOI 10.17487/RFC7228, May 2014,
.
+
+
+Lenders, et al. Expires 16 May 2024 [Page 15]
+
+Internet-Draft dns+cbor November 2023
+
+
+ [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
+ Code: The Implementation Status Section", BCP 205,
+ RFC 7942, DOI 10.17487/RFC7942, July 2016,
+ .
+
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
.
@@ -779,13 +857,6 @@ Internet-Draft dns+cbor October 2023
DOI 10.17487/RFC8724, April 2020,
.
-
-
-Lenders, et al. Expires 15 April 2024 [Page 14]
-
-Internet-Draft dns+cbor October 2023
-
-
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824,
@@ -815,6 +886,18 @@ A.1. DNS Queries
[["example.org", 255, 255]]
+
+
+
+
+
+
+
+Lenders, et al. Expires 16 May 2024 [Page 16]
+
+Internet-Draft dns+cbor November 2023
+
+
A.2. DNS Responses
The responses to the examples provided in Appendix A.1 are shown
@@ -833,15 +916,6 @@ A.2. DNS Responses
[[["example.org", 300, h'20010db8000000000000000000000001']]]
-
-
-
-
-Lenders, et al. Expires 15 April 2024 [Page 15]
-
-Internet-Draft dns+cbor October 2023
-
-
If the query can not be mapped to the response for some reason, a
response would look like:
@@ -858,6 +932,28 @@ Internet-Draft dns+cbor October 2023
Lastly, a response to ["example.org", 255, 255] could be
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lenders, et al. Expires 16 May 2024 [Page 17]
+
+Internet-Draft dns+cbor November 2023
+
+
[
["example.org", 12, 1],
[[3600, "_coap._udp.local"]],
@@ -891,13 +987,6 @@ Internet-Draft dns+cbor October 2023
2001:db8::35 and ns2.example.org at 2001.db8::3535. Each of the
transmitted records has a TTL of 3600 seconds.
-
-
-Lenders, et al. Expires 15 April 2024 [Page 16]
-
-Internet-Draft dns+cbor October 2023
-
-
Appendix B. Comparison to Wire Format
Table 2 shows a comparison between the wire format and the
@@ -916,42 +1005,9 @@ Appendix B. Comparison to Wire Format
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lenders, et al. Expires 15 April 2024 [Page 17]
+Lenders, et al. Expires 16 May 2024 [Page 18]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
+===========+==========+=================+=========================+
@@ -1005,14 +1061,23 @@ Internet-Draft dns+cbor October 2023
-Lenders, et al. Expires 15 April 2024 [Page 18]
+Lenders, et al. Expires 16 May 2024 [Page 19]
-Internet-Draft dns+cbor October 2023
+Internet-Draft dns+cbor November 2023
Appendix C. Change Log
-C.1. Since draft-lenders-dns-cbor-03
+C.1. Since draft-lenders-dns-cbor-04
+ (https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-04)
+
+ * Add Implementation Status section
+
+ * Remove int as representation for rdata
+
+ * Add note on representation of more structured rdata
+
+C.2. Since draft-lenders-dns-cbor-03
(https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-03)
* Provide format description for EDNS OPT Pseudo-RRs
@@ -1021,12 +1086,12 @@ C.1. Since draft-lenders-dns-cbor-03
* Remove DNS transaction IDs
-C.2. Since draft-lenders-dns-cbor-02
+C.3. Since draft-lenders-dns-cbor-02
(https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-02)
* Add Discussion section and note on compression
-C.3. Since draft-lenders-dns-cbor-01
+C.4. Since draft-lenders-dns-cbor-01
(https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-01)
* Use MIME type parameter for packed instead of own MIME type
@@ -1036,7 +1101,7 @@ C.3. Since draft-lenders-dns-cbor-01
* Clarify fallback to wire-format
-C.4. Since draft-lenders-dns-cbor-00
+C.5. Since draft-lenders-dns-cbor-00
(https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-00)
* Add support for DNS transaction IDs
@@ -1049,6 +1114,14 @@ Acknowledgments
TODO acknowledge.
+
+
+
+Lenders, et al. Expires 16 May 2024 [Page 20]
+
+Internet-Draft dns+cbor November 2023
+
+
* Carsten Bormann
Authors' Addresses
@@ -1058,14 +1131,6 @@ Authors' Addresses
Helmholtzstr. 10
D-01069 Dresden
Germany
-
-
-
-Lenders, et al. Expires 15 April 2024 [Page 19]
-
-Internet-Draft dns+cbor October 2023
-
-
Email: martine.lenders@tu-dresden.de
@@ -1108,13 +1173,4 @@ Internet-Draft dns+cbor October 2023
-
-
-
-
-
-
-
-
-
-Lenders, et al. Expires 15 April 2024 [Page 20]
+Lenders, et al. Expires 16 May 2024 [Page 21]
diff --git a/draft-lenders-dns-cbor-04/draft-lenders-dns-cbor.html b/draft-lenders-dns-cbor-04/draft-lenders-dns-cbor.html
deleted file mode 100644
index c78190a..0000000
--- a/draft-lenders-dns-cbor-04/draft-lenders-dns-cbor.html
+++ /dev/null
@@ -1,2136 +0,0 @@
-
-
-
-
-
-
-A Concise Binary Object Representation (CBOR) of DNS Messages
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Internet-Draft
-
dns+cbor
-
October 2023
-
-
-
Lenders, et al.
-
Expires 4 April 2024
-
[Page]
-
-
-
-
-
-
Workgroup:
-
CBOR
-
Internet-Draft:
-
draft-lenders-dns-cbor-latest
-
Published:
-
-
-
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
M. S. Lenders
-
TU Dresden
-
-
-
C. Bormann
-
Universität Bremen TZI
-
-
-
T. C. Schmidt
-
HAW Hamburg
-
-
-
M. Wählisch
-
TU Dresden
-
-
-
-
-
A Concise Binary Object Representation (CBOR) of DNS Messages
This document specifies a compressed data format of DNS messages using
-the Concise Binary Object Representation [RFC8949].
-The primary purpose is to keep DNS messages small in constrained networks.¶
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.¶
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF). Note that other groups may also distribute working
- documents as Internet-Drafts. The list of current Internet-Drafts is
- at https://datatracker.ietf.org/drafts/current/.¶
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."¶
-
- This Internet-Draft will expire on 4 April 2024.¶
- Copyright (c) 2023 IETF Trust and the persons identified as the
- document authors. All rights reserved.¶
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (https://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with
- respect to this document. Code Components extracted from this
- document must include Revised BSD License text as described in
- Section 4.e of the Trust Legal Provisions and are provided without
- warranty as described in the Revised BSD License.¶
In constrained networks [RFC7228], the link layer may restrict the payload sizes to
-only a few hundreds bytes. Encrypted DNS resolution, such as DNS over HTTPS (DoH) [RFC8484] or
-DNS over CoAP (DoC) [I-D.ietf-core-dns-over-coap], may lead to DNS message sizes that exceed this limit, even when
-implementing header compression such as 6LoWPAN IPHC [RFC6282] or SCHC [RFC8724],
-[RFC8824].¶
-
Although adoption layers such as 6LoWPAN [RFC4944] or SCHC [RFC8724] offer fragmentation to
-comply with small MTUs, fragmentation should be avoided in constrained networks, because
-fragmentation combined with high packet loss multiplies the loss. As such, a compression
-format for DNS messages is needed.¶
-
This document specifies a compressed data format for DNS messages. DNS messages are encoded in
-Concise Binary Object Representation (CBOR) [RFC8949] and, additionally, unnecessary or
-redundant information is removed. To use the outcome of this specification in DoH and DoC,
-this document also specifies a Media Type header for DoH and a Content-Format option for DoC.¶
A DNS query is a message that queries DNS information from an upstream DNS resolver.¶
-
The term "constrained networks" is used as defined in [RFC7228].¶
-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
-"MAY", and "OPTIONAL" in this document are to be interpreted as
-described in BCP 14 [RFC2119][RFC8174] when, and only when, they
-appear in all capitals, as shown here.¶
To keep overhead minimal, a DNS message is represented as CBOR arrays. All CBOR items used in
-this specification are of definite length. CBOR arrays that do not follow the length
-definitions of this or follow-up specifications, MUST be silently ignored. It is assumed that
-DNS query and DNS response are distinguished message types and that the query can be mapped to
-the response by the transfer protocol of choice. To define the representation of binary
-objects we use the Concise Data Definition Language (CDDL) [RFC8610].¶
If, for any reason, a DNS message is not representable in the CBOR format specified in this
-document, a fallback to the another DNS message format, e.g., the classic DNS wire format, MUST
-always be possible.¶
Domain names are represented in their commonly known string format (e.g., "example.org", see Section
-2.3.1 in [RFC1035]) and in IDNA encoding [RFC5890] as a text string. For the purpose of this
-document, domain names remain case-insensitive as specified in [RFC1035].¶
-
The representation of a domain name is defined in Figure 2.¶
This document specifies the representation of both standard DNS resource records (RRs, see [RFC1035])
-and EDNS option pseudo-RRs (see [RFC6891]).
-If for any reason, a resource record can not be represented in the given formats, they can be
-represented in their binary wire-format form, as a byte string.¶
-
Further special records, e.g., TSIG can be defined in follow-up specifications and are out of scope
-of this document.¶
-
The representation of a DNS resource records is defined in Figure 3.¶
An optional record class (as unsigned integer), and lastly¶
-
-
A record data entry (as unsigned integer, negative integer, byte string, or text string).¶
-
-
-
If the first item of the resource record is a text string, it is its name.
-If the name is elided, the name is derived from the question section of the message.
-For responses, the question section is either taken from the query (see Section 3.3) or provided
-with the response see Section 3.4.
-The query may be derived from the context of the transfer protocol.¶
-
If the record type is elided, the record type from the question is assumed.
-If record class is elided, the record class from the question is assumed.
-When a record class is required, the record type MUST also be provided.¶
-
The byte format of the record data as a byte string follows the wire format as specified in Section
-3.3 [RFC1035] (or other specifications of the respective record type). Note that this format does
-not include the RDLENGTH field from [RFC1035] as this value is encoded in the length field of the
-CBOR byte string.¶
-
If the record data represents a domain name (e.g., for CNAME or PTR records), the record data MAY be
-represented as a text string as specified in Section 3.1.
-This can save 1 byte of data, because the byte representation of DNS names requires both an
-additional byte to define the length of the first name component and well as a zero byte at the end
-of the name.
-With CBOR on the other hand only 1 byte is required to define type and length of the text string up
-until a string length of 23 characters.
-Likewise, if the record data is purely a numerical value, it can be expressed as either an unsigned
-or negative integer.¶
EDNS OPT Pseudo-RRs are represented as a CBOR array.
-To distinguish them from normal standard RRs, they are marked with tag TBD141.¶
-
Name and record type can be elided as they are always "." and OPT (41), respectively [RFC6891].¶
-
The UDP payload size may be the first element as an unsigned integer in the array but it can be
-elided if it defaults to 512, the maximum allowable size for DNS over UDP [RFC6891].¶
-
The next element is an array of the options, which are represented two elements each, an unsigned
-integer, the option code, followed by a byte string, the option data.
-Multiple options alternate between unsigned integer and byte string within the array.¶
-
After that, up to three unsigned integers are following.
-The first being the extended flags as unsigned integer (implied to be 0 if elided),
-the second the extended RCODE as an unsigned integer (implied to be 0 if elided), and
-the third the EDNS version (implied to be 0 if elided).
-They are dependent on each of their previous elements.
-If the EDNS version is not elided, both extended flags and extended RCODE MUST not be elided.
-If the RCODE is not elided the extended flags MUST not be elided.¶
-
TBD: reverse extended flags to get MSB-defined DO into LSB?¶
-
Note that future EDNS versions may require a different format than the one described above.¶
If the first item of the query is an array, it is the question section, if it is an unsigned
-integer, it is as flag field and maps to the header flags in [RFC1035] and the "DNS Header Flags"
-IANA registry including the QR flag and the Opcode.
-It MUST be lesser than 2^16.¶
This specification assumes that the DNS messages are sent over a transfer protocol that can map the
-queries to their responses, e.g., DNS over HTTPS [RFC8484] or DNS over CoAP [I-D.ietf-core-dns-over-coap].
-As a consequence, the DNS transaction ID is always elided and the value 0 is assumed.¶
-
The question section is encoded as a CBOR array containing up to 3 entries:¶
-
-
The queried name (as text string, see Section 3.1),¶
-
-
An optional record type (as unsigned integer), and¶
-
If the record type is elided, record type AAAA as specified in [RFC3596] is assumed.
-If the record class is elided, record class IN as specified in [RFC1035] is assumed.
-When a record class is required, the record type MUST also be provided.¶
-
The remainder of the query is either empty or MUST consist of up to two arrays.
-The first array, if present, encodes the authority section of the query as an array of DNS
-resource records (see Section 3.2)
-The second array, if present, encodes the additional section of the query as an array of DNS
-resource records (see Section 3.2)¶
-
The representation of a DNS query is defined in Figure 6.¶
As for queries, the DNS transaction ID is elided and implied to be 0.¶
-
If the CBOR array is a response to a query for which the flags indicate that flags are set in the
-response, they MUST be set accordingly and thus included in the response.
-If the flags are not included, the flags are implied to be 0x8000 (everything unset except for the
-QR flag).¶
-
If the response includes only 1 array, this is the DNS answer section represented as an
-array of one or more DNS Resource Records (see Section 3.2).¶
-
If the response includes more than 2 arrays, the first entry may be the question section, identified
-by not being an array of arrays. If it is present, it is followed by the answer section. The
-question section is encoded as specified in Section 3.3.¶
-
If the answer section is followed by 1 additional array, it is the additional section (TBD:
-back choice to favor additional section by empirical data). Like the answer section, the additional
-sections is represented as an array of one or more DNS Resource Records (see Section 3.2).¶
-
If the answer section is followed by 2 additional arrays, the first is the authority section, and
-the second the additional section (TBD: back choice to favor additional section by empirical data).
-The authority section is also represented as an array of one or more DNS Resource Records (see
-Section 3.2).¶
A DNS client uses media type "application/dns+cbor;packed=1" to negotiate (see, e.g.,
-[RFC9110] or [RFC7252], Section 5.5.4) with the DNS server if the server supports packed
-CBOR.
-If it does, it MAY request the response to be in packed CBOR (media type
-"applicaton/dns+cbor;packed=1").
-The server then SHOULD reply with the response in packed CBOR.¶
The representation of DNS responses in packed CBOR has the same semantics as for tag TBD113
-([I-D.ietf-cbor-packed], Section 3.1) with the rump being the compressed response.
-The difference to [I-D.ietf-cbor-packed] is that tag TBD113 is OPTIONAL.¶
-
Packed compression of queries is not specified, as apart from EDNS(0) (see Section 3.2.2), they only
-consist of one question most of the time.¶
How the compressor constructs the packing table, i.e., how the compression is applied, is out of
-scope of this document. Several potential compression algorithms were evaluated in [TBD].¶
IANA is requested to assign CoAP Content-Format ID for the new DNS message media
-types in the "CoAP Content-Formats"
-sub-registry, within the "CoRE Parameters" registry [RFC7252], corresponding the
-"application/dns+cbor" media type specified in Section 7.1:¶
-Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <https://www.rfc-editor.org/rfc/rfc1035>.
-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC3596]
-
-Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, , <https://www.rfc-editor.org/rfc/rfc3596>.
-
-
[RFC5890]
-
-Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, , <https://www.rfc-editor.org/rfc/rfc5890>.
-
-
[RFC6838]
-
-Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/rfc/rfc6838>.
-
-
[RFC6891]
-
-Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, , <https://www.rfc-editor.org/rfc/rfc6891>.
-
-
[RFC7252]
-
-Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <https://www.rfc-editor.org/rfc/rfc7252>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
[RFC8610]
-
-Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <https://www.rfc-editor.org/rfc/rfc8610>.
-
-
[RFC8949]
-
-Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.
-Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, , <https://www.rfc-editor.org/rfc/rfc4944>.
-
-
[RFC6282]
-
-Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, , <https://www.rfc-editor.org/rfc/rfc6282>.
-
-
[RFC7228]
-
-Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, , <https://www.rfc-editor.org/rfc/rfc7228>.
-Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, , <https://www.rfc-editor.org/rfc/rfc8724>.
-
-
[RFC8824]
-
-Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, , <https://www.rfc-editor.org/rfc/rfc8824>.
-
-
[RFC9110]
-
-Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
A DNS query of the record AAAA in class IN for name "example.org" is
-represented in CBOR extended diagnostic notation (EDN) (see Section 8 in
-[RFC8949] and Appendix G in [RFC8610]) as follows:¶
The responses to the examples provided in Appendix A.1 are shown
-below. We use the CBOR extended diagnostic notation (EDN) (see Section 8 in
-[RFC8949] and Appendix G in [RFC8610]).¶
-
To represent an AAAA record with TTL 300 seconds for the IPv6 address 2001:db8::1, a minimal
-response to ["example.org"] could be¶
To represent a minimal response of an A record with TTL 3600 seconds for the IPv4 address
-192.0.2.1, a minimal response to ["example.org", 1] could be¶
This one advertises two local CoAP servers (identified by service name _coap._udp.local) at
-2001:db8::1 and 2001:db8::2 and two nameservers for the example.org domain, ns1.example.org at
-2001:db8::35 and ns2.example.org at 2001.db8::3535. Each of the transmitted records has a TTL of
-3600 seconds.¶
-
-
-
diff --git a/draft-lenders-dns-cbor-04/draft-lenders-dns-cbor.txt b/draft-lenders-dns-cbor-04/draft-lenders-dns-cbor.txt
deleted file mode 100644
index 9e98af0..0000000
--- a/draft-lenders-dns-cbor-04/draft-lenders-dns-cbor.txt
+++ /dev/null
@@ -1,1064 +0,0 @@
-
-
-
-
-CBOR M. S. Lenders
-Internet-Draft TU Dresden
-Intended status: Standards Track C. Bormann
-Expires: 4 April 2024 Universität Bremen TZI
- T. C. Schmidt
- HAW Hamburg
- M. Wählisch
- TU Dresden
- 2 October 2023
-
-
- A Concise Binary Object Representation (CBOR) of DNS Messages
- draft-lenders-dns-cbor-latest
-
-Abstract
-
- This document specifies a compressed data format of DNS messages
- using the Concise Binary Object Representation [RFC8949]. The
- primary purpose is to keep DNS messages small in constrained
- networks.
-
-About This Document
-
- This note is to be removed before publishing as an RFC.
-
- The latest revision of this draft can be found at https://anr-bmbf-
- pivot.github.io/draft-lenders-dns-cbor/draft-lenders-dns-cbor.html.
- Status information for this document may be found at
- https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/.
-
- Discussion of this document takes place on the CBOR Working Group
- mailing list (mailto:cbor@ietf.org), which is archived at
- https://mailarchive.ietf.org/arch/browse/cbor/. Subscribe at
- https://www.ietf.org/mailman/listinfo/cbor/.
-
- Source for this draft and an issue tracker can be found at
- https://github.com/anr-bmbf-pivot/draft-lenders-dns-cbor.
-
-Status of This Memo
-
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at https://datatracker.ietf.org/drafts/current/.
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 1]
-
-Internet-Draft dns+cbor October 2023
-
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on 4 April 2024.
-
-Copyright Notice
-
- Copyright (c) 2023 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents (https://trustee.ietf.org/
- license-info) in effect on the date of publication of this document.
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document. Code Components
- extracted from this document must include Revised BSD License text as
- described in Section 4.e of the Trust Legal Provisions and are
- provided without warranty as described in the Revised BSD License.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. CBOR Representations (application/dns+cbor) . . . . . . . . . 4
- 3.1. Domain Name Representation . . . . . . . . . . . . . . . 4
- 3.2. DNS Resource Records . . . . . . . . . . . . . . . . . . 4
- 3.2.1. Standard RRs . . . . . . . . . . . . . . . . . . . . 5
- 3.2.2. EDNS OPT Pseudo-RRs . . . . . . . . . . . . . . . . . 6
- 3.3. DNS Queries . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.4. DNS Responses . . . . . . . . . . . . . . . . . . . . . . 9
- 4. Name and Address Compression with Packed CBOR . . . . . . . . 10
- 4.1. Media Type Negotiation . . . . . . . . . . . . . . . . . 10
- 4.2. DNS Representation in Packed CBOR . . . . . . . . . . . . 10
- 4.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 10
- 5. Comparison to wire format . . . . . . . . . . . . . . . . . . 10
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 11
- 7.1.1. "application/dns+cbor" . . . . . . . . . . . . . . . 11
- 7.2. CoAP Content-Format Registration . . . . . . . . . . . . 12
- 7.2.1. "application/dns-cbor" . . . . . . . . . . . . . . . 12
- 7.2.2. "application/dns+cbor;packed=1" . . . . . . . . . . . 12
- 7.3. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 12
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
- 8.2. Informative References . . . . . . . . . . . . . . . . . 14
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 2]
-
-Internet-Draft dns+cbor October 2023
-
-
- Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15
- A.1. DNS Queries . . . . . . . . . . . . . . . . . . . . . . . 15
- A.2. DNS Responses . . . . . . . . . . . . . . . . . . . . . . 15
- Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17
- B.1. Since draft-lenders-dns-cbor-03 . . . . . . . . . . . . . 17
- B.2. Since draft-lenders-dns-cbor-02 . . . . . . . . . . . . . 18
- B.3. Since draft-lenders-dns-cbor-01 . . . . . . . . . . . . . 18
- B.4. Since draft-lenders-dns-cbor-00 . . . . . . . . . . . . . 18
- Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
-
-1. Introduction
-
- In constrained networks [RFC7228], the link layer may restrict the
- payload sizes to only a few hundreds bytes. Encrypted DNS
- resolution, such as DNS over HTTPS (DoH) [RFC8484] or DNS over CoAP
- (DoC) [I-D.ietf-core-dns-over-coap], may lead to DNS message sizes
- that exceed this limit, even when implementing header compression
- such as 6LoWPAN IPHC [RFC6282] or SCHC [RFC8724], [RFC8824].
-
- Although adoption layers such as 6LoWPAN [RFC4944] or SCHC [RFC8724]
- offer fragmentation to comply with small MTUs, fragmentation should
- be avoided in constrained networks, because fragmentation combined
- with high packet loss multiplies the loss. As such, a compression
- format for DNS messages is needed.
-
- This document specifies a compressed data format for DNS messages.
- DNS messages are encoded in Concise Binary Object Representation
- (CBOR) [RFC8949] and, additionally, unnecessary or redundant
- information is removed. To use the outcome of this specification in
- DoH and DoC, this document also specifies a Media Type header for DoH
- and a Content-Format option for DoC.
-
-2. Terminology
-
- CBOR types (unsigned integer, byte string, text string, arrays, etc.)
- are used as defined in [RFC8949].
-
- TBD DNS server and client.
-
- A DNS query is a message that queries DNS information from an
- upstream DNS resolver.
-
- The term "constrained networks" is used as defined in [RFC7228].
-
-
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 3]
-
-Internet-Draft dns+cbor October 2023
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
- "OPTIONAL" in this document are to be interpreted as described in
- BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
- capitals, as shown here.
-
-3. CBOR Representations (application/dns+cbor)
-
- To keep overhead minimal, a DNS message is represented as CBOR
- arrays. All CBOR items used in this specification are of definite
- length. CBOR arrays that do not follow the length definitions of
- this or follow-up specifications, MUST be silently ignored. It is
- assumed that DNS query and DNS response are distinguished message
- types and that the query can be mapped to the response by the
- transfer protocol of choice. To define the representation of binary
- objects we use the Concise Data Definition Language (CDDL) [RFC8610].
-
- dns-message = dns-query / dns-response
-
- Figure 1: This document defines both DNS Queries and Responses in
- CDDL
-
- If, for any reason, a DNS message is not representable in the CBOR
- format specified in this document, a fallback to the another DNS
- message format, e.g., the classic DNS wire format, MUST always be
- possible.
-
-3.1. Domain Name Representation
-
- Domain names are represented in their commonly known string format
- (e.g., "example.org", see Section 2.3.1 in [RFC1035]) and in IDNA
- encoding [RFC5890] as a text string. For the purpose of this
- document, domain names remain case-insensitive as specified in
- [RFC1035].
-
- The representation of a domain name is defined in Figure 2.
-
- domain-name = tstr .regexp "([^.]+[.])*[^.]+"
-
- Figure 2: Domain Name Definition
-
-3.2. DNS Resource Records
-
- This document specifies the representation of both standard DNS
- resource records (RRs, see [RFC1035]) and EDNS option pseudo-RRs (see
- [RFC6891]). If for any reason, a resource record can not be
- represented in the given formats, they can be represented in their
- binary wire-format form, as a byte string.
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 4]
-
-Internet-Draft dns+cbor October 2023
-
-
- Further special records, e.g., TSIG can be defined in follow-up
- specifications and are out of scope of this document.
-
- The representation of a DNS resource records is defined in Figure 3.
-
- dns-rr = rr / #6.141(opt-rr) / bstr
-
- Figure 3: DNS Resource Record Definition
-
-3.2.1. Standard RRs
-
- Standard DNS resource records are encoded as CBOR arrays containing 2
- to 5 entries in the following order:
-
- 1. An optional name (as text string, see Section 3.1),
-
- 2. A TTL (as unsigned integer),
-
- 3. An optional record type (as unsigned integer),
-
- 4. An optional record class (as unsigned integer), and lastly
-
- 5. A record data entry (as unsigned integer, negative integer, byte
- string, or text string).
-
- If the first item of the resource record is a text string, it is its
- name. If the name is elided, the name is derived from the question
- section of the message. For responses, the question section is
- either taken from the query (see Section 3.3) or provided with the
- response see Section 3.4. The query may be derived from the context
- of the transfer protocol.
-
- If the record type is elided, the record type from the question is
- assumed. If record class is elided, the record class from the
- question is assumed. When a record class is required, the record
- type MUST also be provided.
-
- The byte format of the record data as a byte string follows the wire
- format as specified in Section 3.3 [RFC1035] (or other specifications
- of the respective record type). Note that this format does not
- include the RDLENGTH field from [RFC1035] as this value is encoded in
- the length field of the CBOR byte string.
-
- If the record data represents a domain name (e.g., for CNAME or PTR
- records), the record data MAY be represented as a text string as
- specified in Section 3.1. This can save 1 byte of data, because the
- byte representation of DNS names requires both an additional byte to
- define the length of the first name component and well as a zero byte
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 5]
-
-Internet-Draft dns+cbor October 2023
-
-
- at the end of the name. With CBOR on the other hand only 1 byte is
- required to define type and length of the text string up until a
- string length of 23 characters. Likewise, if the record data is
- purely a numerical value, it can be expressed as either an unsigned
- or negative integer.
-
- rr = [
- ? name: domain-name,
- ttl: uint,
- ? type-spec,
- rdata: int / bstr / domain-name,
- ]
- type-spec = (
- record-type: uint,
- ? record-class: uint,
- )
-
- Figure 4: DNS Standard Resource Record Definition
-
-3.2.2. EDNS OPT Pseudo-RRs
-
- EDNS OPT Pseudo-RRs are represented as a CBOR array. To distinguish
- them from normal standard RRs, they are marked with tag TBD141.
-
- Name and record type can be elided as they are always "." and OPT
- (41), respectively [RFC6891].
-
- The UDP payload size may be the first element as an unsigned integer
- in the array but it can be elided if it defaults to 512, the maximum
- allowable size for DNS over UDP [RFC6891].
-
- The next element is an array of the options, which are represented
- two elements each, an unsigned integer, the option code, followed by
- a byte string, the option data. Multiple options alternate between
- unsigned integer and byte string within the array.
-
- After that, up to three unsigned integers are following. The first
- being the extended flags as unsigned integer (implied to be 0 if
- elided), the second the extended RCODE as an unsigned integer
- (implied to be 0 if elided), and the third the EDNS version (implied
- to be 0 if elided). They are dependent on each of their previous
- elements. If the EDNS version is not elided, both extended flags and
- extended RCODE MUST not be elided. If the RCODE is not elided the
- extended flags MUST not be elided.
-
- TBD: reverse extended flags to get MSB-defined DO into LSB?
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 6]
-
-Internet-Draft dns+cbor October 2023
-
-
- Note that future EDNS versions may require a different format than
- the one described above.
-
- opt-rr = [
- ? udp-payload-size: uint .default 512,
- options: [* opt],
- ? opt-rcode-v-flags,
- ]
- opt = (
- ocode: uint,
- odata: bstr,
- )
- opt-rcode-v-flags = (
- flags: uint .default 0,
- ? opt-rcode-v,
- )
- opt-rcode-v = (
- rcode: uint .default 0,
- ? version: uint .default 0,
- )
-
- Figure 5: DNS OPT Resource Record Definition
-
-3.3. DNS Queries
-
- DNS queries are encoded as CBOR arrays containing up to 5 entries in
- the following order:
-
- 1. An optional flag field (as unsigned integer),
-
- 2. The question section (as array),
-
- 3. An optional authority section (as array), and
-
- 4. An optional additional section (as array)
-
- If the first item of the query is an array, it is the question
- section, if it is an unsigned integer, it is as flag field and maps
- to the header flags in [RFC1035] and the "DNS Header Flags" IANA
- registry including the QR flag and the Opcode. It MUST be lesser
- than 2^16.
-
- If the flags are elided, the value 0 is assumed.
-
-
-
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 7]
-
-Internet-Draft dns+cbor October 2023
-
-
- This specification assumes that the DNS messages are sent over a
- transfer protocol that can map the queries to their responses, e.g.,
- DNS over HTTPS [RFC8484] or DNS over CoAP
- [I-D.ietf-core-dns-over-coap]. As a consequence, the DNS transaction
- ID is always elided and the value 0 is assumed.
-
- The question section is encoded as a CBOR array containing up to 3
- entries:
-
- 1. The queried name (as text string, see Section 3.1),
-
- 2. An optional record type (as unsigned integer), and
-
- 3. An optional record class (as unsigned integer)
-
- If the record type is elided, record type AAAA as specified in
- [RFC3596] is assumed. If the record class is elided, record class IN
- as specified in [RFC1035] is assumed. When a record class is
- required, the record type MUST also be provided.
-
- The remainder of the query is either empty or MUST consist of up to
- two arrays. The first array, if present, encodes the authority
- section of the query as an array of DNS resource records (see
- Section 3.2) The second array, if present, encodes the additional
- section of the query as an array of DNS resource records (see
- Section 3.2)
-
- The representation of a DNS query is defined in Figure 6.
-
- dns-query = [
- ? flags: uint .default 0x0000,
- question-section,
- ? extra-sections,
- ]
- question-section = [
- name: domain-name,
- ? type-spec,
- ]
- extra-sections = (
- ? authority: [+ dns-rr],
- additional: [+ dns-rr],
- )
-
- Figure 6: DNS Query Definition
-
-
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 8]
-
-Internet-Draft dns+cbor October 2023
-
-
-3.4. DNS Responses
-
- DNS responses are encoded as a CBOR array containing up to 7 entries.
-
- 1. An optional flag field (as unsigned integer),
-
- 2. An optional question section (as array, encoded as described in
- Section 3.3)
-
- 3. The answer section (as array),
-
- 4. An optional authority section (as array), and
-
- 5. An optional additional section (as array)
-
- As for queries, the DNS transaction ID is elided and implied to be 0.
-
- If the CBOR array is a response to a query for which the flags
- indicate that flags are set in the response, they MUST be set
- accordingly and thus included in the response. If the flags are not
- included, the flags are implied to be 0x8000 (everything unset except
- for the QR flag).
-
- If the response includes only 1 array, this is the DNS answer section
- represented as an array of one or more DNS Resource Records (see
- Section 3.2).
-
- If the response includes more than 2 arrays, the first entry may be
- the question section, identified by not being an array of arrays. If
- it is present, it is followed by the answer section. The question
- section is encoded as specified in Section 3.3.
-
- If the answer section is followed by 1 additional array, it is the
- additional section (TBD: back choice to favor additional section by
- empirical data). Like the answer section, the additional sections is
- represented as an array of one or more DNS Resource Records (see
- Section 3.2).
-
- If the answer section is followed by 2 additional arrays, the first
- is the authority section, and the second the additional section (TBD:
- back choice to favor additional section by empirical data). The
- authority section is also represented as an array of one or more DNS
- Resource Records (see Section 3.2).
-
-
-
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 9]
-
-Internet-Draft dns+cbor October 2023
-
-
- dns-response = [
- ? flags: uint .default 0x8000,
- ? question-section,
- answer-section: [+ dns-rr],
- ? extra-sections,
- ]
-
- Figure 7: DNS Response Definition
-
-4. Name and Address Compression with Packed CBOR
-
- If both DNS server and client support packed CBOR
- [I-D.ietf-cbor-packed], it MAY be used for name and address
- compression in DNS responses.
-
-4.1. Media Type Negotiation
-
- A DNS client uses media type "application/dns+cbor;packed=1" to
- negotiate (see, e.g., [RFC9110] or [RFC7252], Section 5.5.4) with the
- DNS server if the server supports packed CBOR. If it does, it MAY
- request the response to be in packed CBOR (media type "applicaton/
- dns+cbor;packed=1"). The server then SHOULD reply with the response
- in packed CBOR.
-
-4.2. DNS Representation in Packed CBOR
-
- The representation of DNS responses in packed CBOR has the same
- semantics as for tag TBD113 ([I-D.ietf-cbor-packed], Section 3.1)
- with the rump being the compressed response. The difference to
- [I-D.ietf-cbor-packed] is that tag TBD113 is OPTIONAL.
-
- Packed compression of queries is not specified, as apart from EDNS(0)
- (see Section 3.2.2), they only consist of one question most of the
- time.
-
-4.3. Compression
-
- How the compressor constructs the packing table, i.e., how the
- compression is applied, is out of scope of this document. Several
- potential compression algorithms were evaluated in [TBD].
-
-5. Comparison to wire format
-
- TBD: Table comparing DNS wire-format, DNS+CBOR, and DNS+CBOR-packed
-
-
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 10]
-
-Internet-Draft dns+cbor October 2023
-
-
-6. Security Considerations
-
- TODO Security
-
-7. IANA Considerations
-
-7.1. Media Type Registration
-
- This document registers a media type for the serialization format of
- DNS messages in CBOR. It follows the procedures specified in
- [RFC6838].
-
-7.1.1. "application/dns+cbor"
-
- Type name: application
-
- Subtype name: dns+cbor
-
- Required parameters: None
-
- Optional parameters: packed
-
- Encoding considerations: Must be encoded as using [RFC8949]. See
- [TBD-this-spec] for details.
-
- Security considerations: See Section 6 of this draft
-
- Interoperability considerations: TBD
-
- Published specification: [TBD-this-spec]
-
- Applications that use this media type: TBD DNS over X systems
-
- Fragment Identifier Considerations: TBD
-
- Additional information:
-
- Deprecated alias names for this type: N/A
-
- Magic number(s): N/A
-
- File extension(s): dnsc
-
- Macintosh file type code(s): none
-
- Person & email address to contact for further information: Martine S.
- Lenders m.lenders@fu-berlin.de (mailto:m.lenders@fu-berlin.de)
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 11]
-
-Internet-Draft dns+cbor October 2023
-
-
- Intended usage: COMMON
-
- Restrictions on Usage: None?
-
- Author: Martine S. Lenders m.lenders@fu-berlin.de
- (mailto:m.lenders@fu-berlin.de)
-
- Change controller: Martine S. Lenders m.lenders@fu-berlin.de
- (mailto:m.lenders@fu-berlin.de)
-
- Provisional registrations? No
-
-7.2. CoAP Content-Format Registration
-
- IANA is requested to assign CoAP Content-Format ID for the new DNS
- message media types in the "CoAP Content-Formats" sub-registry,
- within the "CoRE Parameters" registry [RFC7252], corresponding the
- "application/dns+cbor" media type specified in Section 7.1:
-
-7.2.1. "application/dns-cbor"
-
- Media-Type: application/dns+cbor
-
- Encoding: -
-
- Id: TBD
-
- Reference: [TBD-this-spec]
-
-7.2.2. "application/dns+cbor;packed=1"
-
- Media-Type: application/dns+cbor;packed=1
-
- Encoding: -
-
- Id: TBD
-
- Reference: [TBD-this-spec]
-
-7.3. CBOR Tags Registry
-
- In the registry "CBOR Tags" [IANA.cbor-tags], IANA is requested to
- allocate the tags defined in Table 1.
-
-
-
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 12]
-
-Internet-Draft dns+cbor October 2023
-
-
- +========+===========+===============+========================+
- | Tag | Data Item | Semantics | Reference |
- +========+===========+===============+========================+
- | TBD141 | array | CBOR EDNS | draft-lenders-dns-cbor |
- | | | option record | |
- +--------+-----------+---------------+------------------------+
-
- Table 1: Values for Tag Numbers
-
-8. References
-
-8.1. Normative References
-
- [I-D.ietf-cbor-packed]
- Bormann, C., "Packed CBOR", Work in Progress, Internet-
- Draft, draft-ietf-cbor-packed-09, 10 July 2023,
- .
-
- [IANA.cbor-tags]
- IANA, "Concise Binary Object Representation (CBOR) Tags",
- .
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
- November 1987, .
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119,
- DOI 10.17487/RFC2119, March 1997,
- .
-
- [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
- "DNS Extensions to Support IP Version 6", STD 88,
- RFC 3596, DOI 10.17487/RFC3596, October 2003,
- .
-
- [RFC5890] Klensin, J., "Internationalized Domain Names for
- Applications (IDNA): Definitions and Document Framework",
- RFC 5890, DOI 10.17487/RFC5890, August 2010,
- .
-
- [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
- Specifications and Registration Procedures", BCP 13,
- RFC 6838, DOI 10.17487/RFC6838, January 2013,
- .
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 13]
-
-Internet-Draft dns+cbor October 2023
-
-
- [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
- for DNS (EDNS(0))", STD 75, RFC 6891,
- DOI 10.17487/RFC6891, April 2013,
- .
-
- [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
- Application Protocol (CoAP)", RFC 7252,
- DOI 10.17487/RFC7252, June 2014,
- .
-
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
- 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
- May 2017, .
-
- [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
- Definition Language (CDDL): A Notational Convention to
- Express Concise Binary Object Representation (CBOR) and
- JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
- June 2019, .
-
- [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
- Representation (CBOR)", STD 94, RFC 8949,
- DOI 10.17487/RFC8949, December 2020,
- .
-
-8.2. Informative References
-
- [I-D.ietf-core-dns-over-coap]
- Lenders, M. S., Amsüss, C., Gündoğan, C., Schmidt, T. C.,
- and M. Wählisch, "DNS over CoAP (DoC)", Work in Progress,
- Internet-Draft, draft-ietf-core-dns-over-coap-03, 10 July
- 2023, .
-
- [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
- "Transmission of IPv6 Packets over IEEE 802.15.4
- Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
- .
-
- [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
- Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
- DOI 10.17487/RFC6282, September 2011,
- .
-
- [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
- Constrained-Node Networks", RFC 7228,
- DOI 10.17487/RFC7228, May 2014,
- .
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 14]
-
-Internet-Draft dns+cbor October 2023
-
-
- [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
- (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
- .
-
- [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
- Zuniga, "SCHC: Generic Framework for Static Context Header
- Compression and Fragmentation", RFC 8724,
- DOI 10.17487/RFC8724, April 2020,
- .
-
- [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
- Context Header Compression (SCHC) for the Constrained
- Application Protocol (CoAP)", RFC 8824,
- DOI 10.17487/RFC8824, June 2021,
- .
-
- [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
- Ed., "HTTP Semantics", STD 97, RFC 9110,
- DOI 10.17487/RFC9110, June 2022,
- .
-
-Appendix A. Examples
-
-A.1. DNS Queries
-
- A DNS query of the record AAAA in class IN for name "example.org" is
- represented in CBOR extended diagnostic notation (EDN) (see Section 8
- in [RFC8949] and Appendix G in [RFC8610]) as follows:
-
- [["example.org"]]
-
- A query of an A record for the same name is represented as
-
- [["example.org", 1]]
-
- A query of ANY record for that name is represented as
-
- [["example.org", 255, 255]]
-
-A.2. DNS Responses
-
- The responses to the examples provided in Appendix A.1 are shown
- below. We use the CBOR extended diagnostic notation (EDN) (see
- Section 8 in [RFC8949] and Appendix G in [RFC8610]).
-
- To represent an AAAA record with TTL 300 seconds for the IPv6 address
- 2001:db8::1, a minimal response to ["example.org"] could be
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 15]
-
-Internet-Draft dns+cbor October 2023
-
-
- [[[300, h'20010db8000000000000000000000001']]]
-
- In this case, the name is derived from the query.
-
- If the name or the context is required, the following response would
- also be valid:
-
- [[["example.org", 300, h'20010db8000000000000000000000001']]]
-
- If the query can not be mapped to the response for some reason, a
- response would look like:
-
- [["example.org"], [[300, h'20010db8000000000000000000000001']]]
-
- To represent a minimal response of an A record with TTL 3600 seconds
- for the IPv4 address 192.0.2.1, a minimal response to ["example.org",
- 1] could be
-
- [[300, h'c0000201']]
-
- Note that here also the 1 of record type A can be elided, as this
- record type is specified in the question section.
-
- Lastly, a response to ["example.org", 255, 255] could be
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 16]
-
-Internet-Draft dns+cbor October 2023
-
-
- [
- ["example.org", 12, 1],
- [[3600, "_coap._udp.local"]],
- [
- [3600, 2, "ns1.example.org"],
- [3600, 2, "ns2.example.org"]
- ],
- [
- [
- "_coap._udp.local", 3600, 28,
- h'20010db8000000000000000000000001'
- ],
- [
- "_coap._udp.local", 3600, 28,
- h'20010db8000000000000000000000002'
- ],
- [
- "ns1.example.org", 3600, 28,
- h'20010db8000000000000000000000035'
- ],
- [
- "ns2.example.org", 3600, 28,
- h'20010db8000000000000000000003535'
- ]
- ]
- ]
-
- This one advertises two local CoAP servers (identified by service
- name _coap._udp.local) at 2001:db8::1 and 2001:db8::2 and two
- nameservers for the example.org domain, ns1.example.org at
- 2001:db8::35 and ns2.example.org at 2001.db8::3535. Each of the
- transmitted records has a TTL of 3600 seconds.
-
-Appendix B. Change Log
-
-B.1. Since draft-lenders-dns-cbor-03
- (https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-03)
-
- * Provide format description for EDNS OPT Pseudo-RRs
-
- * Simplify CDDL to more idiomatic style
-
- * Remove DNS transaction IDs
-
-
-
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 17]
-
-Internet-Draft dns+cbor October 2023
-
-
-B.2. Since draft-lenders-dns-cbor-02
- (https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-02)
-
- * Add Discussion section and note on compression
-
-B.3. Since draft-lenders-dns-cbor-01
- (https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-01)
-
- * Use MIME type parameter for packed instead of own MIME type
-
- * Update definitions to accommodate for TID and flags, as well as
- more sections in query
-
- * Clarify fallback to wire-format
-
-B.4. Since draft-lenders-dns-cbor-00
- (https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-00)
-
- * Add support for DNS transaction IDs
-
- * Name and Address compression utilizing CBOR-packed
-
- * Minor fixes to CBOR EDN and CDDL
-
-Acknowledgments
-
- TODO acknowledge.
-
- * Carsten Bormann
-
-Authors' Addresses
-
- Martine Sophie Lenders
- TUD Dresden University of Technology
- Helmholtzstr. 10
- D-01069 Dresden
- Germany
- Email: martine.lenders@tu-dresden.de
-
-
- Carsten Bormann
- Universität Bremen TZI
- Email: cabo@tzi.org
-
-
- Thomas C. Schmidt
- HAW Hamburg
- Email: t.schmidt@haw-hamburg.de
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 18]
-
-Internet-Draft dns+cbor October 2023
-
-
- Matthias Wählisch
- TUD Dresden University of Technology
- Helmholtzstr. 10
- D-01069 Dresden
- Germany
- Email: m.waehlisch@tu-dresden.de
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lenders, et al. Expires 4 April 2024 [Page 19]
diff --git a/draft-lenders-dns-cbor-04/index.html b/draft-lenders-dns-cbor-04/index.html
deleted file mode 100644
index abbf81e..0000000
--- a/draft-lenders-dns-cbor-04/index.html
+++ /dev/null
@@ -1,45 +0,0 @@
-
-
-
- anr-bmbf-pivot/draft-lenders-dns-cbor draft-lenders-dns-cbor-04 preview
-
-
-
-
-