]> 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 TBD Internet-Draft CBOR DNS This document provides guidance on the composition of DNS messages in constrained networks, where the link layer may restrict payload sizes significantly and batteries challenge power consumption. 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 TBD Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Many IoT scenarios rely on constrained nodes and need the Domain Name System (DNS). Constrained nodes , however, challenge DNS resolution for two reasons. First, IoT networks, such as IEEE 802.15.4 and LoRaWAN, often limit the payload of the data link layer significantly in terms of size, which prevents common (larger) DNS responses. Second, constrained nodes are often battery powered and follow a strict duty cycle, which would benefit from minimal number of DNS messages to reduce unnecessary device wake-ups. Adoption layers such as 6LoWPAN and SCHC provide fragmentation and compression to overcome the problem, but do not help in principle. Fragmentation requires more buffer space to account for lost fragments in lossy networks, and compression introduces additional processing overhead. This document provides best common practices on DNS behavior, to reduce fragmentation and power consumption in constrained networks when IoT nodes resolve names.

Terminology A "DNS server" is a server that provides DNS information to a querying DNS client. For the purpose of this document, server and client may communicate based on any DNS transport, not just DNS over UDP , but also DNS over TLS , DNS over HTTPS , or DNS over CoAP . The terms "constrained node" and "constrained network" are 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.

Constrained Resolver Considerations Nodes within a constrained network that implement DNS are assumed to be stub resolvers . This means they only query information from a recursive DNS resolver and they MUST NOT distribute any DNS information received from an upstream DNS server.

DNS Server Consideration A DNS server that is aware that the querying node is a node within a constrained network SHOULD resolve a CNAME or PTR record until the resource record type originally requested by the node is reached. This reduces the number of message exchanges within a constrained network. The DNS server SHOULD send compact answers, i.e., omit additional or authority sections in a DNS reply. Additional and authority sections should only be included if they help a DNS client to reduce queries. One such example is DNS-SD , where the answer does not only need to include an SRV record but also TXT and A/AAAA records to make decent use of the reply. TBD: Provide more specific example use case? Should the list be almost complete?

Security Considerations In the case when DNS clients act as DNS servers, resolving CNAME and PTR records at the upstream DNS server may lead to incorrect DNS information forwarded by the client. As such, this document prohibits the distribution of such information in TODO more security

IANA Considerations This document has no IANA actions.

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. 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. 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] 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 describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. 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. 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 sometimes 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 obsoletes RFC 7719 and updates RFC 2308. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. 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).

Acknowledgments TODO acknowledge.

• Carsten Bormann
• Ben Schwartz