A Concise Binary Object Representation (CBOR) of DNS Messages
Internet-Draft draft-lenders-dns-cbor-08
Martine Sophie Lenders
TUD Dresden University of Technology
Helmholtzstr. 10
Dresden
D-01069
Germany
martine.lenders@tu-dresden.de
Carsten Bormann
Universität Bremen TZI
Postfach 330440
Bremen
D-28359
Germany
+49-421-218-63921
cabo@tzi.org
Thomas C. Schmidt
HAW Hamburg
t.schmidt@haw-hamburg.de
Matthias Wählisch
TUD Dresden University of Technology & Barkhausen Institut
Helmholtzstr. 10
Dresden
D-01069
Germany
m.waehlisch@tu-dresden.de
28 June 2024
Applications
CBOR
Internet-Draft
CBOR
DNS
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
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.
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.
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].
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.
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].
This document defines both DNS Queries and Responses in CDDL

dns-message = dns-query / dns-response

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 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.
TBD: represent names as components ((* tstr)), provide name compression when [I-D.ietf-cbor-packed] is updated for the reference format and table building discussed at IETF 118.
Domain Name Definition

domain-name = tstr .regexp "([^.]+[.])*[^.]+"

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.
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 Resource Record Definition

dns-rr = rr / #6.141(opt-rr) / bstr

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 classic DNS 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.
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.
DNS Standard Resource Record Definition

rr = [
  ? name: domain-name,
  ttl: uint,
  ? type-spec,
  rdata: bstr / domain-name,
]
type-spec = (
  record-type: uint,
  ? record-class: uint,
)

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. It MUST be elided if its value is the default value of 512, the maximum allowable size for unextended DNS over UDP (see Sections 2.3.4 and 4.2.1 of [RFC1035]).
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.
DNS OPT Resource Record Definition

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,
)

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.
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.
A question within 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.
If more than one question is supposed to be in the question section, the next question just follows. In this case, for every question but the last, the record type MUST be included, i.e., it is not optional. This way it is ensured that the parser can distinguish each question by looking up the name first (TBD note: this is especially relevant once the name is split up in components).
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 Definition

dns-query = [
  ? flags: uint .default 0x0000,
  question-section,
  ? extra-sections,
]
question-section = [
  * full-question,
  ? last-question,
]
full-question = (
  name: domain-name,
  type-spec,
)
last-question = (
  name: domain-name,
  ? type-spec,
)
extra-sections = (
  ? authority: [+ dns-rr],
  additional: [+ dns-rr],
)

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 section 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).
DNS Response Definition

dns-response = [
  ? flags: uint .default 0x8000,
  ? question-section,
  answer-section: [+ dns-rr],
  ? extra-sections,
]

Name and Address Compression with CBOR-packed
If both DNS server and client support CBOR-packed [I-D.ietf-cbor-packed], it MAY be used for name and address compression in DNS responses.
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 CBOR-packed (media type "applicaton/dns+cbor;packed=1"). The server then SHOULD reply with the response in CBOR-packed.
DNS Representation in CBOR-packed
The representation of DNS responses in CBOR-packed 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.
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].
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".
Python decoder/encoder
The authors of this document provide a decoder/encoder implementation of both the unpacked and packed format specified in this document in Python.
Level of maturity:
prototype
Version compatibility:
draft-lenders-dns-cbor-05
License:
MIT
Contact information:
Martine Lenders <martine.lenders@tu-dresden.de>
Last update of this information:
October 2023
Embedded decoder/encoder
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.
Level of maturity:
prototype
Version compatibility:
draft-lenders-dns-cbor-05
License:
MIT
Contact information:
Martine Lenders <martine.lenders@tu-dresden.de>
Last update of this information:
October 2023
Security Considerations
TODO Security
IANA Considerations
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].
"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
Intended usage: COMMON
Restrictions on Usage: None?
Author: Martine S. Lenders m.lenders@fu-berlin.de
Change controller: Martine S. Lenders m.lenders@fu-berlin.de
Provisional registrations? No
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:
"application/dns+cbor"
Media-Type: application/dns+cbor
Encoding: -
Id: TBD
Reference: [TBD-this-spec]
"application/dns+cbor;packed=1"
Media-Type: application/dns+cbor;packed=1
Encoding: -
Id: TBD
Reference: [TBD-this-spec]
CBOR Tags Registry
In the registry "CBOR Tags" [IANA.cbor-tags], IANA is requested to allocate the tags defined in Table 1.
Values for Tag Numbers
Tag | Data Item | Semantics | Reference
TBD141 | array | CBOR EDNS option record | draft-lenders-dns-cbor
References
Normative References
[RFC1035]

Domain names - implementation and specification
P. Mockapetris
November 1987
STD 13
RFC 1035
DOI 10.17487/RFC1035
[RFC3596]

DNS Extensions to Support IP Version 6
S. Thomson
C. Huitema
V. Ksinant
M. Souissi
October 2003
STD 88
RFC 3596
DOI 10.17487/RFC3596
[RFC6891]

Extension Mechanisms for DNS (EDNS(0))
J. Damas
M. Graff
P. Vixie
April 2013
STD 75
RFC 6891
DOI 10.17487/RFC6891
[RFC7252]

The Constrained Application Protocol (CoAP)
Z. Shelby
K. Hartke
C. Bormann
June 2014
RFC 7252
DOI 10.17487/RFC7252
[RFC8610]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
[RFC8949]

Concise Binary Object Representation (CBOR)
C. Bormann
P. Hoffman
December 2020
STD 94
RFC 8949
DOI 10.17487/RFC8949
[I-D.ietf-cbor-packed]

Packed CBOR
Carsten Bormann
Universität Bremen TZI
Mikolai Gütschow
TUD Dresden University of Technology
2 March 2024
Internet-Draft draft-ietf-cbor-packed-12
[IANA.cbor-tags]

Concise Binary Object Representation (CBOR) Tags
IANA
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC5890]

Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
J. Klensin
August 2010
RFC 5890
DOI 10.17487/RFC5890
[RFC6838]

Media Type Specifications and Registration Procedures
N. Freed
J. Klensin
T. Hansen
January 2013
BCP 13
RFC 6838
DOI 10.17487/RFC6838
Informative References
[RFC4944]

Transmission of IPv6 Packets over IEEE 802.15.4 Networks
G. Montenegro
N. Kushalnagar
J. Hui
D. Culler
September 2007
RFC 4944
DOI 10.17487/RFC4944
[RFC6282]

Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
J. Hui, Ed.
P. Thubert
September 2011
RFC 6282
DOI 10.17487/RFC6282
[RFC7228]

Terminology for Constrained-Node Networks
C. Bormann
M. Ersue
A. Keranen
May 2014
RFC 7228
DOI 10.17487/RFC7228
[RFC8484]

DNS Queries over HTTPS (DoH)
P. Hoffman
P. McManus
October 2018
RFC 8484
DOI 10.17487/RFC8484
[RFC8724]

SCHC: Generic Framework for Static Context Header Compression and Fragmentation
A. Minaburo
L. Toutain
C. Gomez
D. Barthel
JC. Zuniga
April 2020
RFC 8724
DOI 10.17487/RFC8724
[RFC8824]

Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
A. Minaburo
L. Toutain
R. Andreasen
June 2021
RFC 8824
DOI 10.17487/RFC8824
[RFC9110]

HTTP Semantics
R. Fielding, Ed.
M. Nottingham, Ed.
J. Reschke, Ed.
June 2022
STD 97
RFC 9110
DOI 10.17487/RFC9110
[I-D.ietf-core-dns-over-coap]

DNS over CoAP (DoC)
Martine Sophie Lenders
TUD Dresden University of Technology
Christian Amsüss
Cenk Gündoğan
Huawei Technologies
Thomas C. Schmidt
HAW Hamburg
Matthias Wählisch
TUD Dresden University of Technology & Barkhausen Institut
4 March 2024
Internet-Draft draft-ietf-core-dns-over-coap-06
[RFC7942]

Improving Awareness of Running Code: The Implementation Status Section
Y. Sheffer
A. Farrel
July 2016
BCP 205
RFC 7942
DOI 10.17487/RFC7942
Examples
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]]

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

[[[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

[
  ["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.
Comparison to Classic DNS Wire Format
Table 2 shows a comparison between the classic DNS wire format and the application/dns+cbor format. Note that the worst case results typically appear only rarely in DNS. The classic DNS format is preferred in those cases. A key for which configuration was used in which case can be seen in Table 3.
Comparison of application/dns+cbor to classic DNS format.
Item | Classic DNS format [bytes] | application/dns+cbor [bytes]
best case | realistic worst case | theoretical worst case
Header (ID & Flags) | 4 | 1 | 4 | 4
Count fields | 2 | 1 | 3 | 3
Question section | 6 + name len. | 2 + name len. | 7 + name len. | 10 + name len.
Standard RR | 12 + name len. + rdata len. | 3 + rdata len. | 15 + name len. + rdata len. | 18 + name len. + rdata len.
EDNS Opt Pseudo-RR | 11 + options | 2 + options | 6 + options | 14 + options
EDNS Option | 4 + value len. | 2 + value len. | 4 + value len. | 6 + value len.
Configuration key for Table 2 .
Item | application/dns+cbor configuration
best case | realistic worst case | theoretical worst case
Header (ID & Flags) | Flags elided | QR, Opcode, AA, TC, or RD are set | QR, Opcode, AA, TC, or RD are set
Count fields | Encoded in CBOR array header | Encoded in CBOR array header, >255 records in section | Encoded in CBOR array header, >255 records in section
Question section | Class, type, and name elided | Type > 255, name len. > 255 | Type > 255, Class > 255, name len. > 255
Standard RR | Class, type, and name elided, rdata len. < 24 | Type > 255, name len. > 255 rdata len. > 255 | Type > 255, Class > 255, name len. > 255 rdata len. > 255
EDNS Opt Pseudo-RR | All EDNS(0) fields elided | Rcode < 24, DO flag set, | UDP payload len. > 255 Rcode > 255 Version > 255 DO flag set
EDNS Option | Code < 24 Length < 24 | Code < 24 Length > 255 | Code > 255 Length > 255
Change Log
Since draft-lenders-dns-cbor-07
- Add Appendix B with comparison to classic DNS wire format
- "wire format" -> "classic DNS wire format"
Since draft-lenders-dns-cbor-06
- Fixes wording and spelling mistakes
Since draft-lenders-dns-cbor-05
- Fix Section 7.2.1 title
- Amend for capability to carry more than one question
- Hint at future of name compression in later draft versions
- Use canonical name for CBOR-packed
Since draft-lenders-dns-cbor-04
- Add Implementation Status section
- Remove int as representation for rdata
- Add note on representation of more structured rdata
Since draft-lenders-dns-cbor-03
- Provide format description for EDNS OPT Pseudo-RRs
- Simplify CDDL to more idiomatic style
- Remove DNS transaction IDs
Since draft-lenders-dns-cbor-02
- Add Discussion section and note on compression
Since 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
Since 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.