Skip to main content

A Concise Binary Object Representation (CBOR) of DNS Messages
draft-lenders-dns-cbor-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Martine Sophie Lenders , Carsten Bormann , Thomas C. Schmidt , Matthias Wählisch
Last updated 2023-03-13
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lenders-dns-cbor-02
CBOR                                                       M. S. Lenders
Internet-Draft                                                 FU Berlin
Intended status: Standards Track                              C. Bormann
Expires: 14 September 2023                        Universität Bremen TZI
                                                           T. C. Schmidt
                                                             HAW Hamburg
                                                             M. Wählisch
                                                               FU Berlin
                                                           13 March 2023

     A Concise Binary Object Representation (CBOR) of DNS Messages
                       draft-lenders-dns-cbor-02

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 14 September 2023               [Page 1]
Internet-Draft                  dns+cbor                      March 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 14 September 2023.

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.  Standard DNS Resource Records (RRs) . . . . . . . . . . .   4
     3.3.  DNS Queries . . . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  DNS Responses . . . . . . . . . . . . . . . . . . . . . .   7
     3.5.  EDNS(0) . . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.6.  Name and Address Compression with Packed CBOR . . . . . .   9
       3.6.1.  Table Setup . . . . . . . . . . . . . . . . . . . . .  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Media Type Registration . . . . . . . . . . . . . . . . .  12
       5.1.1.  "application/dns+cbor"  . . . . . . . . . . . . . . .  12
     5.2.  CoAP Content-Format Registration  . . . . . . . . . . . .  13
       5.2.1.  "application/dns-cbor"  . . . . . . . . . . . . . . .  13
       5.2.2.  "application/dns+cbor;packed=1" . . . . . . . . . . .  13
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  15
     A.1.  DNS Queries . . . . . . . . . . . . . . . . . . . . . . .  15
     A.2.  DNS Responses . . . . . . . . . . . . . . . . . . . . . .  16
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  17
     B.1.  Since [draft-lenders-dns-cbor-01] . . . . . . . . . . . .  17

Lenders, et al.         Expires 14 September 2023               [Page 2]
Internet-Draft                  dns+cbor                      March 2023

     B.2.  Since draft-lenders-dns-cbor-00 . . . . . . . . . . . . .  17
   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].

   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.

Lenders, et al.         Expires 14 September 2023               [Page 3]
Internet-Draft                  dns+cbor                      March 2023

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
   transport 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.

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 1.

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

                      Figure 1: Domain Name Definition

3.2.  Standard DNS Resource Records (RRs)

   DNS resource records are encoded either in their binary form as a
   byte string or 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).

Lenders, et al.         Expires 14 September 2023               [Page 4]
Internet-Draft                  dns+cbor                      March 2023

   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
   transport context.

   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.

   The representation of a DNS resource records is defined in Figure 2.

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

                  Figure 2: DNS Resource Record Definition

Lenders, et al.         Expires 14 September 2023               [Page 5]
Internet-Draft                  dns+cbor                      March 2023

3.3.  DNS Queries

   DNS queries are encoded as CBOR arrays containing up to 5 entries in
   the following order:

   1.  An optional transaction ID (as unsigned integer),

   2.  An optional flag field (as unsigned integer),

   3.  The question section (as array),

   4.  An optional authority section (as array), and

   5.  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 the transaction ID.  If
   the transaction ID is present and followed by another unsigned
   integer, that item is a 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 transaction ID is elided, the value 0 is assumed, same for the
   flags.  The transaction ID MUST be included and set to an
   unpredictable value lesser than 2^32, if the DNS transport can not
   ensure the prevention of DNS response spoofing.  An example for such
   a transport is unencrypted DoC (see [I-D.ietf-core-dns-over-coap],
   Section 6).

   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.

Lenders, et al.         Expires 14 September 2023               [Page 6]
Internet-Draft                  dns+cbor                      March 2023

   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 3.

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

                       Figure 3: DNS Query Definition

3.4.  DNS Responses

   DNS responses are encoded as a CBOR array containing up to 7 entries.

   1.  An optional transaction ID (as unsigned integer),

   2.  An optional flag field (as unsigned integer),

   3.  An optional question section (as array, encoded as described in
       Section 3.3)

   4.  The answer section (as array),

   5.  An optional authority section (as array), and

   6.  An optional additional section (as array)

Lenders, et al.         Expires 14 September 2023               [Page 7]
Internet-Draft                  dns+cbor                      March 2023

   If the CBOR array is a response to a query that contains a
   transaction ID, it MUST be included and set to the corresponding
   value present in the query.  If it is not included, the transaction
   ID is 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 2 arrays, the first entry is a question
   section and the second entry is an answer section.  The question
   section is encoded like as specified in Section 3.3, the answer
   section is represented as an array of one or more DNS Resource
   Records (see Section 3.2).

   If the response includes 3 arrays, the first section is a question
   section, the second an answer section, and the third an additional
   section (TBD: back choice to favor additional section by empirical
   data).  Again, the question section is encoded like a DNS query as
   specified in Section 3.3 and both answer and additional sections are
   represented each as an array of one or more DNS Resource Records (see
   Section 3.2).

   If the response includes 4 arrays, the first section is a question
   section, the second an answer section, the third an authority
   section, and the fourth an additional section (TBD: back by empirical
   data).  They follow the specification of 3 arrays in the answer.  The
   authority section is also represented as an array of one or more DNS
   Resource Records (see Section 3.2).

Lenders, et al.         Expires 14 September 2023               [Page 8]
Internet-Draft                  dns+cbor                      March 2023

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

                     Figure 4: DNS Response Definition

3.5.  EDNS(0)

   TBD, do we need special formatting here?

3.6.  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.

   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 differs, in that
   responses are now represented as a CBOR array of two arrays.  The
   first array is a packing table that is used both as shared item table
   and argument table (see [I-D.ietf-cbor-packed], Section 2.1), the
   second is the compressed response.

   The representation of a packed DNS response is defined in Figure 5.

    compr-dns-response = any /TBD; how to express packed CBOR in CDDL?/
    packed-dns-response = [[pack-table], compr-dns-response]
    pack-table = any

            Figure 5: Definition of DNS messages in packed CBOR

Lenders, et al.         Expires 14 September 2023               [Page 9]
Internet-Draft                  dns+cbor                      March 2023

   If an index in the packing table is referenced with shared item
   reference ([I-D.ietf-cbor-packed], Section 2.2) a decoder uses the
   packing table as a shared item table.  If an index in the packing
   table is referenced as an argument ([I-D.ietf-cbor-packed], Sections
   2.3 and 4), a decoder uses the packing table as an argument table.

   Discussion TBD:

   *  For queries, as they are only one question, i.e. at most one value
      of each at most, compression is not necessary.

   *  Address and name compression are mostly about affix compression
      (i.e. straight/inverse referencing)
      ==> For occasions were value is the affix (e.g., "example.org" in
      ANY example in Appendix A.2) use shared item referencing to
      argument table to safe bytes (no extra shared item table, no,
      e.g., 216(""), just simple(0))

      -  *Example:* Using Basic Packed CBOR ([I-D.ietf-cbor-packed],
         section 3.1):

         o  131 bytes (Basic Packed CBOR)

         o  200 bytes (plain CBOR, see Appendix A.2)

         o  194 bytes (wire-format)

            113(
              [
                ["_coap._udp.local", "example.org", 3600, 28, 2],
                [h'20010db800000000000000000000', simple(1)],
                [
                  [simple(1), 12, 1],
                  [[simple(1), simple(0)]],
                  [
                    [simple(1), simple(4), 217("ns1.")],
                    [simple(1), simple(4), 217("ns2.")]
                  ],
                  [
                    [simple(0), simple(1), simple(3), 6(h'0001')],
                    [simple(0), simple(1), simple(3), 6(h'0002')],
                    [217("ns1."), simple(1), simple(3), 6(h'0035')],
                    [217("ns2."), simple(1), simple(3), 6(h'3535')]
                  ]
                ]
              ]
            )

Lenders, et al.         Expires 14 September 2023              [Page 10]
Internet-Draft                  dns+cbor                      March 2023

         vs. application/dns+cbor;packed=1 (shared and argument table as
         one) 126 bytes:

            [
              [
                h'20010db800000000000000000000',
                "_coap._udp.local" "example.org", 3600, 28, 2
              ],
              [
                [simple(2), 12, 1],
                [[simple(3), simple(1)]],
                [
                  [simple(2), simple(5), 218("ns1.")],
                  [simple(2), simple(5), 218("ns2.")]
                ],
                [
                  [simple(1), simple(3), simple(4), 6(h'0001')],
                  [simple(1), simple(3), simple(4), 6(h'0002')],
                  [218("ns1."), simple(3), simple(4), 6(h'0035')],
                  [218("ns2."), simple(3), simple(4), 6(h'3535')]
                ]
              ]
            ]

3.6.1.  Table Setup

   TBD How to construct the packing table, here's a sketch:

   *  Find most often used prefix and values

      -  Probably some threshold needed, to prevent, e.g., 1 byte
         prefixes filling valuable table space

   *  Sort descending by number of occurrences and length

      -  Long prefixes should take precedence for index 0 for Tag 6
         usage

4.  Security Considerations

   TODO Security

5.  IANA Considerations

Lenders, et al.         Expires 14 September 2023              [Page 11]
Internet-Draft                  dns+cbor                      March 2023

5.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].

5.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 4 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)

   Intended usage: COMMON

   Restrictions on Usage: None?

   Author: Martine S.  Lenders m.lenders@fu-berlin.de
   (mailto:m.lenders@fu-berlin.de)

Lenders, et al.         Expires 14 September 2023              [Page 12]
Internet-Draft                  dns+cbor                      March 2023

   Change controller: Martine S.  Lenders m.lenders@fu-berlin.de
   (mailto:m.lenders@fu-berlin.de)

   Provisional registrations?  No

5.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 5.1:

5.2.1.  "application/dns-cbor"

   Media-Type: application/dns+cbor

   Encoding: -

   Id: TBD

   Reference: [TBD-this-spec]

5.2.2.  "application/dns+cbor;packed=1"

   Media-Type: application/dns+cbor;packed=1

   Encoding: -

   Id: TBD

   Reference: [TBD-this-spec]

6.  References

6.1.  Normative References

   [I-D.ietf-cbor-packed]
              Bormann, C., "Packed CBOR", Work in Progress, Internet-
              Draft, draft-ietf-cbor-packed-08, 23 January 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cbor-
              packed-08>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

Lenders, et al.         Expires 14 September 2023              [Page 13]
Internet-Draft                  dns+cbor                      March 2023

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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, October 2003,
              <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, August 2010,
              <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, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <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,
              May 2017, <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,
              June 2019, <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, December 2020,
              <https://www.rfc-editor.org/rfc/rfc8949>.

6.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-01, 24
              October 2022, <https://datatracker.ietf.org/doc/html/
              draft-ietf-core-dns-over-coap-01>.

Lenders, et al.         Expires 14 September 2023              [Page 14]
Internet-Draft                  dns+cbor                      March 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,
              <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, September 2011,
              <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, May 2014,
              <https://www.rfc-editor.org/rfc/rfc7228>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

   [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,
              <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, June 2021,
              <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, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

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

Lenders, et al.         Expires 14 September 2023              [Page 15]
Internet-Draft                  dns+cbor                      March 2023

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

   [[[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 14 September 2023              [Page 16]
Internet-Draft                  dns+cbor                      March 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-01]

   *  Update definitions to accommodate for TID and flags, as well as
      more sections in query

   *  Clarify fallback to wire-format

B.2.  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

Lenders, et al.         Expires 14 September 2023              [Page 17]
Internet-Draft                  dns+cbor                      March 2023

   *  Minor fixes to CBOR EDN and CDDL

Acknowledgments

   TODO acknowledge.

   *  Carsten Bormann

Authors' Addresses

   Martine Sophie Lenders
   Freie Universität Berlin
   Email: m.lenders@fu-berlin.de

   Carsten Bormann
   Universität Bremen TZI
   Email: cabo@tzi.org

   Thomas C. Schmidt
   HAW Hamburg
   Email: t.schmidt@haw-hamburg.de

   Matthias Wählisch
   Freie Universität Berlin
   Email: m.waehlisch@fu-berlin.de

Lenders, et al.         Expires 14 September 2023              [Page 18]