Internet-Draft dns+cbor October 2022
Lenders, et al. Expires 21 April 2023 [Page]
Workgroup:
CBOR
Internet-Draft:
draft-lenders-dns-cbor-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. S. Lenders
FU Berlin
T. C. Schmidt
HAW Hamburg
M. Wählisch
FU Berlin

A Concise Binary Object Representation (CBOR) of DNS Messages

Abstract

This document specifies a compressed data format of DNS messages using the Concise Binary Object Representation [RFC7049]. 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/.

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 21 April 2023.

Table of Contents

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) [RFC7049] 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 [RFC7049].

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.

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

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. DNS Queries

DNS queries are encoded as CBOR arrays containing up to 3 entries in the following order: The name (as text string, see Section 3.1), an optional record type (as unsigned integer), and 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. If a record class is required, the record type MUST also be provided.

The representation of a DNS query is defined in Figure 2.

type-spec = (
  record-type: uint,
  ? record-class: uint,
)
dns-question = (
  name: domain-name,
  ? type: type-spec,
)
dns-query = [dns-question]
Figure 2: DNS Query Definition

3.3. Standard DNS Resource Records (RRs)

DNS resource records are encoded as CBOR arrays containing 2 to 5 entries in the following order: An optional name (as text string, see Section 3.1), a TTL (as unsigned integer), an optional record type (as unsigned integer), an optional record class (as unsigned integer), and lastly a record data entry (as byte string or text string).

If the first element of the resource record is a string, the first element is a name. If the name is elided, the name from the query, either derived from transport context or the provided question section, see Section 3.4, is assumed. 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. If a record class is required, the record type MUST also be provided.

The byte format of the record data 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 and only 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 bytes of data, because the byte representation of DNS names requires both an additional byte to define the length of the first name component as well as a 0 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.

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

rr = (
  ? name: domain-name,
  ttl: uint,
  ? type: record-type,
  rdata: bstr / domain-name,
)
dns-rr = [rr]
Figure 3: DNS Resource Record Definition

3.4. DNS Responses

DNS responses are encoded as array of CBOR arrays containing up to 4 entries.

If only 1 array is included, then this is the DNS answer section represented as an array of one or more DNS Resource Records (see Section 3.3).

If 2 arrays are included, then the first entry is a question section and the second entry is an answer section. The question section is encoded like a DNS query as specified in Section 3.2, the answer section is represented as an array of one or more DNS Resource Records (see Section 3.3).

If 3 arrays are included, then 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.2 and both answer and additional sections are represented each as an array of one or more DNS Resource Records (see Section 3.3).

If 4 arrays are included, then 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.3).

extra-sections = (
  ? authority: [1* dns-rr],
  additional: [1* dns-rr],
)
sections = (
  answer: [1* dns-rr],
) // (
  question: dns-query,
  answer: [1* dns-rr],
  ? extra: extra-sections,
)
dns-response = [sections]
Figure 4: DNS Response Definition

3.5. EDNS(0)

TBD, do we need special formatting here?

4. Security Considerations

TODO Security

5. IANA Considerations

5.1. Media Type Registration

This document registers the media type for the serialization format of DNS messages in CBOR. It follows the procedures specified in [RFC6838].

Type name: application

Subtype name: dns+cbor

Required parameters: None

Optional parameters: None

Encoding considerations: Must be encoded as using [RFC7049]. 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

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

5.2. CoAP Content-Format Registration

IANA is requested to assign CoAP Content-Format ID for the DNS message media type 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:

Media-Type: application/dns+cbor

Encoding: -

Id: TBD

Reference: [TBD-this-spec]

6. References

6.1. Normative References

[RFC1035]
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>.
[RFC7049]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, , <https://www.rfc-editor.org/rfc/rfc7049>.
[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>.

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-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap-00>.
[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, , <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>.
[RFC8484]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, , <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, , <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>.

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 [RFC7049] 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 [RFC7049] 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", 255, 255],
  [[3600, 12, "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.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Martine Sophie Lenders
Freie Universität Berlin
Thomas C. Schmidt
HAW Hamburg
Matthias Wählisch
Freie Universität Berlin