]> Freie Universität Berlin

m.lenders@fu-berlin.de

HAW Hamburg

t.schmidt@haw-hamburg.de

Freie Universität Berlin

m.waehlisch@fu-berlin.de

Applications CBOR Internet-Draft CBOR DNS This document specifies a compressed data format of DNS messages using the Concise Binary Object Representation . 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 . Status information for this document may be found at . Discussion of this document takes place on the CBOR Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In constrained networks , the link layer may restrict the payload sizes to only a few hundreds bytes. Encrypted DNS resolution, such as DNS over HTTPS (DoH) or DNS over CoAP (DoC) , may lead to DNS message sizes that exceed this limit, even when implementing header compression such as 6LoWPAN IPHC or SCHC , . Although adoption layers such as 6LoWPAN or SCHC 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) 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 . A DNS query is a message that queries DNS information from an upstream DNS resolver. The term "constrained networks" is used as defined in . 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 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 transport protocol of choice. To define the representation of binary objects we use the Concise Data Definition Language (CDDL) .

Domain Name Representation Domain names are represented in their commonly known string format (e.g., "example.org", see Section 2.3.1 in ) and in IDNA encoding as a text string. For the purpose of this document, domain names remain case-insensitive as specified in . The representation of a domain name is defined in .

Domain Name Definition

DNS Queries DNS queries are encoded as CBOR arrays containing up to 3 entries in the following order: The name (as text string, see ), 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 is assumed. If the record class is elided, record class IN as specified in is assumed. If a record class is required, the record type MUST also be provided. The representation of a DNS query is defined in .

DNS Query Definition

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 ), 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 , 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 (or other specifications of the respective record type). Note that this format does not include the RDLENGTH field from 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 . 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 .

DNS Resource Record Definition

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 ). 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 , the answer section is represented as an array of one or more DNS Resource Records (see ). 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 and both answer and additional sections are represented each as an array of one or more DNS Resource Records (see ). 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 ).

DNS Response Definition

EDNS(0) TBD, do we need special formatting here?

Security Considerations TODO Security

IANA Considerations

Media Type Registration This document registers the media type for the serialization format of DNS messages in CBOR. It follows the procedures specified in . Type name: application Subtype name: dns+cbor Required parameters: None Optional parameters: None Encoding considerations: Must be encoded as using . See [TBD-this-spec] for details. Security considerations: See 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 DNS message media type in the "CoAP Content-Formats" sub-registry, within the "CoRE Parameters" registry , corresponding the "application/dns+cbor" Media Type specified in : Media-Type: application/dns+cbor Encoding: - Id: TBD Reference: [TBD-this-spec]

References Normative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK] The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. Informative References This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK] This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK] The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. Freie Universität Berlin HAW Hamburg HAW Hamburg Freie Universität Berlin This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT).

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 and Appendix G in ) as follows: A query of an A record for the same name is represented as A query of ANY record for that name is represented as

DNS Responses The responses to the examples provided in are shown below. We use the CBOR extended diagnostic notation (EDN) (see Section 8 in and Appendix G in ). To represent an AAAA record with TTL 300 seconds for the IPv6 address 2001:db8::1, a minimal response to ["example.org"] could be 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: If the query can not be mapped to the response for some reason, a response would look like: 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 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 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.