]> TUD Dresden University of Technology

Helmholtzstr. 10 Dresden D-01069 Germany martine.lenders@tu-dresden.de

Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

TUD Dresden University of Technology

Helmholtzstr. 10 Dresden D-01069 Germany mikolai.guetschow@tu-dresden.de

HAW Hamburg

t.schmidt@haw-hamburg.de

TUD Dresden University of Technology & Barkhausen Institut

Helmholtzstr. 10 Dresden D-01069 Germany m.waehlisch@tu-dresden.de

Applications CBOR Internet-Draft CBOR DNS This document specifies a compact 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 of frames 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. Fragmentation combined with high packet loss multiplies the likelihood of loss. Hence, a compression format that reduces fragmentation of DNS messages is beneficial. This document specifies a compact data format for DNS messages using Concise Binary Object Representation (CBOR) encoding. Additionally, unnecessary or redundant information are stripped off DNS messages. To use the outcome of this specification in DoH and DoC, this document also specifies a Media Type header value for DoH and a Content-Format option value for DoC. Note, that there is another format that expresses DNS messages in CBOR, C-DNS . C-DNS is primarily a file format to minimize traces of multiple DNS messages and uses the fact that there are multiple messages to do its compression. Common values such as names or addresses are collected in separate tables which are referenced from the messages, comparable to Packed CBOR . However, this may add overhead for individual DNS messages. The format described in this document is a transfer format that aims to provide conciseness and compression for individual DNS messages to be sent over the network. This is achieved applying the following objectives: Conciseness:

• Encoding DNS messages in CBOR and
• Omitting (redundant) fields in DNS queries and responses.

Compression:

• Providing easy to implement name compression that allows for on-the-fly construction of DNS queries and responses and
• Providing optional address and value compression in DNS responses using Packed CBOR .

Terminology and Conventions CBOR types (unsigned integer, byte string, text string, arrays, etc.) are used as defined in . The terms "DNS server", "DNS client", and "(DNS) resolver" are used as defined in . A DNS query is a message that queries DNS information from an upstream DNS resolver. The reply to that is a DNS response. The DNS message format specified in for DNS over UDP we call "classic DNS format" throughout this document or refer to it by its media type "application/dns-message" as specified in . 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. To define the representation of binary objects we use the Concise Data Definition Language (CDDL) . For examples, we use the CBOR Extended Diagnostic Notation with the e'' application extension for external references to values .

CBOR Representations (application/dns+cbor) DNS messages in "application/dns+cbor" are represented as CBOR arrays to minimize overhead compared to, e.g., maps. All CBOR items used in this specification are of definite length. CBOR arrays that do not follow the length definitions of this or of follow-up specifications, MUST be silently ignored. CBOR arrays that exceed the message size provided by the transport, 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.

This document defines both DNS Queries and Responses in CDDL

If, for any reason, a DNS message cannot be represented in the CBOR format specified in this document, or if unreasonable overhead is introduced, a fallback to another DNS message format, e.g., the classic DNS format specified in , MUST always be possible. The DNS transport MUST support a mechanism to distinguish different formats, e.g., the Media Type header with DoH.

Domain Name Representation Domain names are represented by a sequence of one or more (Unicode) text strings, using one string per label. For instance, "example.org" would be represented as "example","org" in CBOR diagnostic notation. The root domain "." is represented as an empty string "". The absence of any label means the name is elided. For the purpose of this document, domain names remain case-insensitive as specified in . The representation of a domain name is defined in . A label may either be encoded in ASCII-compatible encoding (ACE) embedded within UTF-8 encoding of the text strings or plain UTF-8. It is RECOMMENDED to use the encoding with the shorter length in bytes, otherwise message sizes may increase. A decoder identifies the ACE encoding by identifying the label as a valid A-label (see ) and MUST assume the label to be encoded in UTF-8 otherwise. This sequence of text strings is supposed to be embedded into a surrounding array, usually the query or resource record. Name compression is implemented using an extension to Packed CBOR, see . For readers unfamiliar with Packed CBOR this name compression can be abstracted to a name compression similar to that described in . However, instead of using the byte index as reference within the message, text strings are counted, starting at 0, depth-first within the message. That number is used as index for the reference. Since names are the only text strings in a CBOR-based DNS message, the end of a name can be identified when the decoder cursor does not point to a text string or reference to another text string anymore. For the reference itself, either simple values or tag 6 are used (see ).

Domain Name Definition

DNS Resource Records This document specifies the representation of both standard DNS resource records (RRs, see ) and EDNS option pseudo-RRs (see . If for any reason, a resource record cannot be represented in the given formats, they can be represented in their binary wire-format form as a byte string. Further dedicated representations of standard resource records, e.g., for TSIG , can be defined in follow-up specifications using the $$structured-ts-rd extension point (see ) and are out of scope of this document. The representation of a DNS resource records is defined in .

DNS Resource Record Definition

Standard RRs Standard DNS resource records are encoded as CBOR arrays containing 2 or more entries in the following order:

1. An optional name (as domain name, see ),
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 byte string, domain name, or array for dedicated record data representation) or a boolean (true) that indicates that the resource record is actually a resource record set with an array of one or more record data entries following. In the latter case, individual domain names need to be put into their own array.

If the first item of the resource record is a text string, it is the first label of a domain name (see ). 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 ) or provided with the response see . 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 to be expressed, the record type MUST also be provided. The byte string format of the record data as a byte string follows the classic DNS format as specified in (or other specifications of the respective record type). Note that the CBOR format does not include the RDLENGTH field from the classic format as this value is encoded in the length field of the CBOR header of the byte string. A parser of the format specified in this document MUST ensure that encoded lengths within this binary record do not overflow the bounds of the byte string or fail otherwise. If the record data represents a domain name (e.g., for CNAME or PTR records), the record data MAY be represented as domain name as specified in . This way of representing the record data means that name compression (see ) can also be used on it. Depending on the record type, the record data may also be expressed as an array. Some initial array types are specified below. Future specifications can extend the definition for $$structured-ts-rd in . Extensions to that in this document mainly serve to expose names to name compression (see ). There is an argument to be made for CBOR-structured formats of other record data representations (e.g. DNSKEY or RRSIG), but structuring such records as an array usually adds more overhead than just transferring the byte representation. As such, structured record data that do not contain names are to be represented as a byte string in this specification. Multiple resource records of the same type, class, and TTL can be summarized to a resource record set. A decoder can be notified about this, by including the boolean true value before an array of multiple record data entries of the same type. Note, that this adds more overhead to the message and should only really be considered, when there are more than one resource records of the same type, class, and TTL in the message.

DNS Standard Resource Record Definition

SOA Record Data The record data of RRs with record-type = 6 (SOA) MAY be expressed as an array with at least 7 entries representing the 7 parts of the SOA resource record defined in in the following order:

• MNAME as a domain name (see ),
• SERIAL as an unsigned integer,
• REFRESH as an unsigned integer,
• RETRY as an unsigned integer,
• EXPIRE as an unsigned integer,
• MINIMUM as an unsigned integer, and
• RNAME as a domain name (see ).

MNAME and RNAME are put to the beginning and end of the array, respectively, to keep their labels apart. The definition for SOA record data can be seen in .

SOA Resource Record Data Definition

MX Record Data The record data of RRs with record-type = 15 (MX) MAY be expressed as an array with at least 2 entries representing the 2 parts of the MX resource record defined in in the following order:

• PREFERENCE as an unsigned integer and
• EXCHANGE as a domain name (see ).

The definition for MX record data can be seen in .

MX Resource Record Data Definition

SRV Record Data The record data of RRs with record-type = 33 (SRV) MAY be expressed as an array with at least 3 entries representing the parts of the SRV resource record defined in in the following order:

• Priority as an unsigned integer,
• an optional Weight as an unsigned integer,
• Port as an unsigned integer,
• Target as a domain name (see ).

If the weight is present or not can be determined by the number of unsigned integers before Target. 2 unsigned integers before the Target mean the weight was elided and defaults to 0. 3 unsigned integers before the Target mean the weight is in the second position of the record data array. The default of 0 was picked, as this is the value domain administrators should pick when there is no server selection to do . The definition for SRV record data can be seen in .

SRV Resource Record Data Definition

SVCB and HTTPS Record Data The record data of RRs with record-type = 64 (SVCB) and record-type = 65 (HTTPS) MAY be expressed as an array with at least 3 entries representing the 3 parts of the SVCB/HTTPS resource record defined in in the following order:

• An optional SvcPriority as an unsigned integer,
• An optional TargetName as a domain name (see ), and
• SvcParams as an array of alternating pairs of SvcParamKey (as unsigned integer) and SvcParamValue (as byte string). The type of SvcParamValue may be extended in future specifications.

It can be determined if the SvcPriority is present by checking if the record data array starts with an unsigned integer or not. If the array does not start with an unsigned integer, the SvcPriority is elided and defaults to 0, i.e., the record is in AliasMode (see ). If the array starts with an unsigned integer, it is the SvcPriority. It can be determined if the TargetName is present by checking if the record data array has a domain name after the SvcPriority, i.e., if the SvcPriority is elided the array would start with a domain name. If there is no domain name after the SvcPriority, the TargetName is elided and defaults to the sequence of text strings "" (i.e., the root domain "." in the common name representation defined in , see and ). If there is a domain name after the SvcPriority, the TargetName is not elided and in the domain name form specified in . The definition for SVCB and HTTPS record data can be seen in .

SVCB and HTTPS Resource Record Data Definition

The SvcParams are provided as an array rather than a map, as their order needs to be preserved which can not be guaranteed for maps.

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 . 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 and of ). The next element is an array of the options as alternating pairs of option code (as unsigned integer) and option data (as byte string). The type of the option data may be extended in future specifications. As per , the order of options is not defined in this specification, but the considerations to order provided in also apply here. 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. Note that future EDNS versions may require a different format than the one described above.

DNS OPT Resource Record Definition

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

1. An optional boolean field,
2. An optional flag field (as unsigned integer),
3. The question section (as array),
4. An optional answer section (as array),
5. An optional authority section (as array), and
6. An optional additional section (as array)

If the first item is a boolean and when true, it tells the responding resolver that it MUST include the question section in its response. If that boolean is not present, it is assumed to be false. 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 and the "DNS Header Flags" IANA registry including the QR flag and the OPCODE. 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 or DNS over CoAP . As a consequence, the DNS transaction ID is always elided and the value 0 is assumed. A question record within the question section is encoded as a CBOR array containing the following entries:

1. The queried name (as domain name, see ) which MUST not be elided,
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 is assumed. If the record class is elided, record class IN as specified in is assumed. When a record class is required, the record type MUST also be provided. There usually is only one question record , which is why the question section is a flat array and not nested like the other sections. This serves to safe overhead from the additional CBOR array header. In the rare cases when there is more than one question record 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. The remainder of the query is either empty or MUST consist of up to three extra arrays. If one extra array is in the query, it encodes the additional section of the query as an array of DNS resource records (see ). If two extra arrays are in the query, they encode, in that order, the authority and additional sections of the query each as an array of DNS resource records (see ). If three extra arrays are in the query, they encode, in that order, the answer section, the authority, and additional sections of the query each as an array of DNS resource records (see ). As such, the highest precedence of elision is given to the answer section, as it only occurs with mDNS to signify Known Answers . The lowest precedence of elision is given to the additional section, as it may contain EDNS OPT Pseudo-RRs, which are common in queries (see ). The representation of a DNS query is defined in .

DNS Query Definition

DNS Responses A DNS response is encoded as a CBOR array containing up to 5 entries.

1. An optional flag field (as unsigned integer),
2. An optional question section (as array, encoded as described in )
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 one array, then the DNS answer section represents an array of one or more DNS Resource Records (see ). If the response includes more than 2 arrays, the first entry may be the question section, identified by just being a flat array and not an array of arrays. It MUST be included, if the client requested it using the boolean field in the query, otherwise it is OPTIONAL. If it is present, it is followed by the answer section. The question section is encoded as specified in . If the answer section is followed by one extra array, this array is the additional section. Like the answer section, the additional section is represented as an array of one or more DNS Resource Records (see ). If the answer section is followed by two extra arrays, the first is the authority section, and the second is the additional section. The authority section is also represented as an array of one or more DNS Resource Records (see ). The authority section is given precedence of elision over the additional section, as due to EDNS options or, e.g., CNAME answers that also provide the A/AAAA records. The additional section tends to show up more often than the authority section.

DNS Response Definition

Compression with Packed CBOR Packed CBOR is used for name compression in "application/dns+cbor". If both DNS server and client support table setup tag 113 as described in , it MAY be used for further compression in DNS responses. Especially IPv6 addresses, e.g., in AAAA resource records can benefit from straight referencing to compress common address prefixes.

Name Compression

CDDL for name compression based on Packed CBOR and as defined in this document.

For name compression, a new packing table setup tag TBD28259 ('n' and 'c' in ASCII) for Packed CBOR is defined. Any "application/dns+cbor" encoder and decoder MUST support tag TBD28259 for DNS queries and responses. It provides an implicit text string suffix sequence table for shared items V. This table V is appended to the existing table for shared items of any table setup tag enclosing tag TBD28259 (by default empty table). This implicit (i.e., not explicitly represented) table V is constructed as follows: Any coherent sequence of text strings encountered within the rump of tag TBD28259 when reading it depth-first, as well as any of its non-empty suffixes, ordered by their appearance within the rump, are added to the table as arrays marked with the splice integration tag 1115 (see ). If a sequence for which a tagged array is already in V is encountered, a shared item reference i is added to the rump instead, splicing the content of the array within tag 1115 into the existing array (see ) and that sequence as well as its non-empty suffixes are not added again to V. The resulting rump should look like referencing the first instance of the i-th complete string sequence (depth first) in the sequence. It is NOT RECOMMENDED to use any other table building tag as defined in within TBD28259, as the implicit table of TBD28259 may otherwise lead to more complicating en- and decoding steps. Particularly, a one-pass decoding with minimal state of DNS messages SHOULD be ensured to be viable on constrained devices. If another table setup needs to be transported within TBD28259, e.g., certain RDATA or option values might elect to use Packed CBOR as well, they SHOULD be encapsulated as encoded CBOR within a byte string using tag 24 . Due to the order of strings being important, special care should be taken for the order of map (major type 5, ) elements within tag TBD28259. The "application/dns+cbor" media type specified within this document avoids maps for this reason, in addition to enforcing orders derived from DNS specifications, e.g., for SvcParams. If any other CBOR object than an object defined by dns-message in is compressed using TBD28259, map elements MUST be encoded in bytewise lexicographic order of their keys, as specified in , unless the definition of that particular object type provides a different predetermined order. The "application/dns+cbor" media type comes with an optional parameter "packed". If it is not provided, the value of it is assumed to be 0. With the "application/dns+cbor;packed=0" media type (i.e., even with "application/dns+cbor"), the tag TBD28259 is implicit, i.e., it SHOULD NOT be sent. This avoids sending the 3 bytes of overhead generated by the presence of the tag. If the decoder encounters an object marked with "application/dns+cbor;packed=0" that is tagged TBD28259, it MUST NOT discard it and parse its content as if it were implicit. Otherwise, it might incur an additional message to be sent and media type negotiation might fail unnecessarily. The splice integration tag 1115 is the only integration tag in use for "application/dns+cbor" for "packed=0" and "packed=1" (see ). Name compression with an example message can be found in .

Further DNS Representation with Tag 113 The representation of DNS responses with packed value 1, i.e., "application/dns+cbor;packed=1", has the same semantics as for tag TBD113 (see ) compressing the name-compressed response as rump. The difference to is that tag TBD113 is implicit with media type parameter "packed=1", see . Take the following definition:

Definition of packed DNS message with media type "application/dns+cbor;packed=1".

When marked by the "application/dns+cbor;packed=1" media type and parameter it MUST be implicitly understood as the definition provided in .

The implicit definition of a packed DNS message with media type "application/dns+cbor;packed=1".

If the decoder encounters an object marked with "application/dns+cbor;packed=1" that is tagged TBD113 or with its rump tagged TBD28259, it MUST NOT discard it and parse its content as if it were implicit. Any object marked with "application/dns+cbor;packed=1" that does not fit the definition of packed-dns-message provided in or variants of explicit tags TBD113 or TBD28259 MUST be interpreted as an invalid message. "packed=1" compression of queries is not specified, as apart from EDNS(0) (see ), they only consist of one question most of the time, i.e., there is close to no redundancy that is not already covered by "packed=0" and encoding such an object can be too complex for a potentially constrained resolver. An example of this mechanism, as well as pseudo-code for a simple decoder can be found in .

Media Type Negotiation A DNS client tells a server that it would accept the media type "application/dns+cbor;packed=1" to negotiate (see, e.g., or ) with the DNS server whether the server supports setup table tag TBD113. If it does, it MAY request the response to be in packed value 1 (media type "application/dns+cbor;packed=1"). The server then SHOULD reply with the response in Packed CBOR, which it also signals with media type "application/dns+cbor;packed=1". Otherwise, both fall back to the implicit "packed=0".

Compression The method of the compressor to construct the packing table, i.e., how the compression is applied, is out of scope of this document.

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 . 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 , "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-10

License:

MIT

Contact information:

Martine Lenders <martine.lenders@tu-dresden.de>

Last update of this information:

July 2024

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

License:

MIT

Contact information:

Martine Lenders <martine.lenders@tu-dresden.de>

Last update of this information:

October 2023

Security Considerations The security considerations of and also apply for this document. For original binary wire format DNS data encoded as byte strings, such as RRs, RDATA, SvcParamValues, or EDNS OPT data, a parser MUST ensure that any encoded lengths within that byte string do not overflow the bounds of the byte string or fail otherwise.

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 .

"application/dns+cbor" Type name: application Subtype name: dns+cbor Required parameters: None Optional parameters: packed 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: IETF CBOR Working Group (cbor@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org) Intended usage: COMMON Restrictions on Usage: None? Author: Martine S. Lenders m.lenders@fu-berlin.de Change controller: IETF 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 , corresponding the "application/dns+cbor" media type specified in :

"application/dns+cbor" Media-Type: application/dns+cbor Encoding: - Id: TBD53 Reference: [TBD-this-spec]

"application/dns+cbor;packed=1" Media-Type: application/dns+cbor;packed=1 Encoding: - Id: TBD54 Reference: [TBD-this-spec]

CBOR Tags Registry In the registry "" , IANA is requested to allocate the tags defined in . Values for Tag Numbers

Tag	Data Item	Semantics	Reference
TBD141	array	CBOR EDNS option record	draft-lenders-dns-cbor
TBD28259	any	Packed CBOR; implicit text string suffix sequence shared-item table	draft-lenders-dns-cbor

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] This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK] The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. 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. 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. 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 obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Universität Bremen TZI TUD Dresden University of Technology The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) 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. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the recipient needs to decompress the compressed form before it can make use of the data. This specification describes Packed CBOR, a set of CBOR tags and simple values that enable a simple transformation of an original CBOR data item into a Packed CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the recipient. // (This cref will be removed by the RFC editor:) The present // revision -19 is a work-in-progress release in preparation for // another cbor-packed side meeting. This revision resolves the use // of the tunables A/B/C by setting A=16, B=8, and C=8, and choosing // requested simple values and tag numbers, in preparation for // continuing the early allocation process. Universität Bremen TZI This document formalizes and consolidates the definition of the Concise Diagnostic Notation (CDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing CDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) This is the // editorial round focusing on editorial cleanup, specifically where // that causes moving text around. It does not have WG input yet on // any renaming decisions (CDN name, b1/t1 name), ABNF cleanup, or // Rohan's suggestion to fix the questionable figure in 3.8. Universität Bremen TZI The Concise Binary Object Representation (CBOR, RFC 8949) 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. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN. IANA 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 describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [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. Informative References The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. 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 describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic- monitoring applications. 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document updates RFC 1035 by constraining the allowed value of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) to a maximum of one, and it specifies the required behavior when values that are not allowed are encountered. This document defines a protocol for exchanging DNS queries (OPCODE 0) over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by (D)TLS-Secured CoAP or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. 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. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Examples

CDDL model for e'' application extension shows the CDDL model used for the e'' application extension for external references to values in our examples. C- contants define DNS classes as unsigned integers from the "DNS CLASSes" sub-registry of the IANA "Domain Name System (DNS) Parameters" registry. RR- constants define resource record types from the "Resource Record (RR) TYPEs" sub-registry of the IANA "Domain Name System (DNS) Parameters" registry.

CDDL model defining constants for this document for e''.

DNS Queries A DNS query of the record AAAA in class IN for name "example.org" is represented in CBOR extended diagnostic notation (EDN) with e'' application extension as follows: The binary (in hexadecimal encoding) of the query looks as follows (14 bytes): A query of an A record for the same name is represented as or in binary (15 bytes) A query of an ANY record for that name is represented as or in binary (18 bytes)

Name Compression Take the following response o in CBOR extended diagnostic notation (EDN) . It contains a question for the "www.example.org" AAAA record, with a "svc.www.example.org" CNAME answer and its AAAA record, as well as the "org.example.org" NS record for the "example.org" domain in the authority section, each record with TTL 3600:

Unpacked example for implicit name compression.

The object o would be sent over the wire as the following 136 bytes of binary data, represented here with hexadecimal encoding (type and data noted in comment).

Binary of the unpacked example for implicit name compression (136 bytes).

With name compression, o would generate the following virtual table V.

Implicit table of shared items for the example _o_.

An implementation MAY choose to use references here to reduce memory consumption, as represented in . Circular references are not possible due to the construction algorithm of V.

Implicit table of shared items for the example _o_ with self-references.

Note that the sequence "org", simple(0) is added at index 4 with leading "org", instead of referencing index 2 + index 1 (simple(2), simple(1)), as it is its own distinct suffix sequence. However, its suffix "example", "org" is not added to the table again, as it is already present at index 1. Assuming media type "application/dns+cbor;packed=0" (i.e., an implicit tag TBD28259), the packed representation of o would thus be:

The packed representation of the name compression example.

In binary the packed representation of o would be:

Binary of the packed representation of the example (65 bytes).

DNS Responses The responses to the examples provided in are shown below. We use the CBOR extended diagnostic notation (EDN) (see and ), most notably the "ip" extension to represent binary IP addresses as an IP address app-string literal, with e'' application extension for external references to values . To represent an AAAA record with TTL 300 seconds for the IPv6 address 2001:db8::1, a minimal response to [["example", "org"]] could be or in binary (23 bytes) 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: In binary that response looks like the following (35 bytes): If the query can not be mapped to the response for some reason or is explicitly requested by the client, a response would look like: In binary that response looks like the following (36 bytes): 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 or in binary (11 bytes) Note that here also record type A can be elided, as this record type is specified in the (equally elided) question section. Lastly, a response to [["example", "org", e'RR-ANY', e'C-ANY']] could be ["example", "org"] to virtual packing table "example", # appends 1 => ["org"] to virtual packing table "org", e'RR-PTR' ], # Answer section: [[ # PTR (12) for "example.org" # (both elided since they are the same as in question) # is "_coap._udp.local" with TTL 3600 3600, # appends 2 => ["_coap", "_udp", "local"] to virtual packing table "_coap", # appends 3 => ["_udp", "local"] to virtual packing table "_udp", # appends 4 => ["local"] to virtual packing table "local" ]], # Authority section: [ [ # NS (2) for "example.org" # (name elided since its the same as in question) # is "ns1.example.org" with TTL 3600 3600, e'RR-NS', # appends 5 => ["ns1", simple(0)] to virtual packing table "ns1", simple(0) # expands to ["example", "org"] ], [ # NS (2) for "example.org" # (name elided since its the same as in question) # is "ns2.example.org" with TTL 3600 3600, e'RR-NS', # appends 6 => ["ns2", simple(0)] to virtual packing table "ns2", simple(0) # expands to ["example", "org"] ] ], # Additional section [ [ # AAAA (28) for "_coap._udp.local" # is 2001:db8::1 with TTL 3600 simple(2), # expands to ["_coap", "_udp", "local"] 3600, e'RR-AAAA', ip'2001:db8::1' ], [ # AAAA (28) for "_coap._udp.local" # is 2001:db8::2 with TTL 3600 simple(2), # expands to ["_coap", "_udp", "local"] 3600, e'RR-AAAA', ip'2001:db8::2' ], [ # AAAA (28) for "ns1.example.org" # is 2001:db8::35 with TTL 3600 simple(5), # expands to ["ns1", ["example", "org"]] 3600, e'RR-AAAA', ip'2001:db8::35' ], [ # AAAA (28) for "ns2.example.org" # is 2001:db8::3535 with TTL 3600 simple(6), # expands to ["ns2", ["example", "org"] 3600, e'RR-AAAA', ip'2001:db8::3535' ] ] ] ]]> or in binary (155 bytes) This response 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. Note the use of name compression (see ) in this example.

Name Compression and Packed CBOR shows the example from with "packed=1".

The packed representation of the example of a message marked with "application/dns+cbor;packed=1".

Note, that the encoder needs to rewrite the references from as the implicit table V is appended to the shared argument table ["org", 600]. In binary, that example looks like the following (represented in hexadecimal):

The binary of the packed representation of the example marked with "application/dns+cbor;packed=1" (62 bytes).

Implicitly, a decoder would interpret this as the following EDN:

The explicit interpretation of the packed representation of the example of a message marked with "application/dns+cbor;packed=1".

Example Decoder A decoder to interpret an object like the one in would have the following pseudo-code:

Pseudo-code for an example decoder outer_table_len) { /* close name_start_idx pointing to first element of name * sequence, as only CBORTextStrings (including those * referenced in outer tables) continue the name */ name_start_idx = null } } } if (is_splice_tag(packed_obj)) { /* name suffix is spliced in */ assume that ( typeof(tag-content of packed_obj) is CBORArray containing only CBORTextString and references to CBORTextString ) result = result concat tag-content of packed_obj } else { append packed_obj to result } } else { /* not part of a name anymore, so close name_start_idx pointing to * first element of name sequence */ name_start_idx = null match typeof(elem) { /* step into arrays and tags */ when CBORArray then { result = result concat recursive_unpack_names( elem, unpacker, outer_table_len ) } when CBORTag then { append CBORTag( tag-number = tag-number of elem, tag-content = recursive_unpack_names( tag-content of elem, unpacker, outer_table_len ), ) to result } when CBORMap then { throw warning "Ignore maps which are not part of this spec" } when anything else then { append elem to result } } } } return result } when anything else then { throw warning "Ignore other types not part of this spec" } } } ]]>

Comparison to Classic DNS Wire Format 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 . Any name label that is longer than 23 bytes adds a name overhead of 1 byte to its CBOR type header.TBD: Also add structured RRs?. 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.	6 + name len. + name overhead	9 + name len. + name overhead
Standard RR	12 + name len. + rdata len.	3 + rdata len.	14 + name len. + rdata len. + name overhead	17 + name len. + rdata len. + name overhead
Standard RR with name rdata	12 + name len. + rdata len.	4	14 + name len. + rdata len. + name overheads	16 + name len. + rdata len. + name overheads
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 .

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, label len. > 23	Type > 255, Class > 255, label len. > 23
Standard RR	Class, type, and name elided, rdata len. < 24	Type > 255, label len. > 23 rdata len. > 255	Type > 255, Class > 255, label len. > 23 rdata len. > 255
Standard RR with name rdata	Class, type, and name elided, simple(i) with i < 16	Type > 255, label len. > 23 name uncompressed	Type > 255, Class > 255, label len. > 23 name uncompressed
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-17

• Re-instate appendix
• Use BCP 219 for DNS terminology
• Fix broken example syntax
• Add security considerations
• Editorial updates

Since draft-lenders-dns-cbor-16

• Minor editorial updates

Since draft-lenders-dns-cbor-15

• Add Vadim Goncharov as contributor
• Add Mikolai Gütschow as co-author
• Make options in OPT record a flat list of alternating key-value-pairs
• Use e'' application extension in examples for better readability of RR types and clases
• Pass on name compression
  • TBD28259 now appends, rather than prepends to existing packing tables to allow for single pass decoders with minimum state.
  • Consequently, disallow inner table setup tags to TBD28259, as that would increase complexity of both decoders and encoders
  • Add considerations on maps within TBD28259 (see also #15)
  • Clarify implicit nature with packed
  • Provide actual DNS examples
  • Add example decoder as pseudo-code

Since draft-lenders-dns-cbor-14

• Correction and nits
• Explicitly state which integration tags are in use
• Add binary examples in CBOR-pretty
• Unify formatting for and mention explicitly application/dns+cbor from the top
• Explicitly define behavior for query[0] = True in response text
• Clarifications around media type parameter packed=1
• Remove TBD reference (it never came to be)

Since draft-lenders-dns-cbor-13

• Make use of splicing integration tag 1115
  • Make domain names flat text string sequences again
• Add capability to summarize rrsets
• Provide extension point for IP addresses

Since draft-lenders-dns-cbor-12

• Fix bug in packed examples
• Improve compression examples for clarity

Since draft-lenders-dns-cbor-11

• Update repo links to cbor-wg org in draft
• s/CBOR-packed/Packed CBOR/
• Small pass on wording
• Remove commented-out parts
• Make name compression be based on Packed CBOR

Since draft-lenders-dns-cbor-10

• Address IANA #1392416 early review
• Fix external section references
• Update implementation status

Since draft-lenders-dns-cbor-09

• Add recommendation on label encoding
• Provide extension points
  • Mark dns-rr specifically as extension point
  • Provide extension points for parameter values (options and svc-params)
• Point out CBOR-packed needs to be unpacked when identifying names
• Distinguish from C-DNS
• State objectives in introduction
• Fix nits and typos

Since draft-lenders-dns-cbor-08

• Clarify why question section was designed the way it is
• Add answer section to queries for Known Answers in mDNS
• Express names as sequence of labels
• Provide dedicated types for more structured RDATA
• Add RFC1035-like name compression
• Add switching boolean to query message to explicitly have question present in response
• Make EDNS options a map
• Update examples and comparison table in appendices
• Update implementation section

Since draft-lenders-dns-cbor-07

• Add 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 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 We want to extend special thanks to Christian Amsüss for his input in the brainstorming session that resulted in the current form of name compression.

Contributors

vadimnuclight@gmail.com