]> Inria

abhishek.mishra@inria.fr

UCL

andrew.losty.23@ucl.ac.uk

UCL

a.mandalari@ucl.ac.uk

Infoblox

jmozley@infoblox.com

Inria

mathieu.cunche@inria.fr

ops iotops This document outlines best current practices for Internet of Things (IoT) device providers regarding the implementation of DNS stub resolvers, with the aim of mitigating security threats, enhancing privacy, and resolving operational challenges. It also provides guidelines for network operators on mitigating the risks identified in this draft as DNS resolution includes services outside of the stub-resolver, and for device providers' management zones. The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Research into the DNS behavior of IoT devices shows widespread non-compliance with protocol standards, gaps in protocol support, and security vulnerabilities. This leads to unpredictable operational behavior and exposes devices to fingerprinting and denial-of-service attacks. While the recommendations in this BCP may apply to all DNS stub resolver behavior, we treat IoT devices as a specific case where targeted recommendations are useful for the following reasons: The recommendations address specific IoT-related security concerns not seen in the DNS behavior of general-purpose operating systems IoT devices have different resource characteristics from general-purpose devices, such as constrained power consumption, meaning incorrect software implementations can have an increased operational impact IoT devices do not typically have security agents installed on them There are many DNS RFCs, and this BCP can be used to identify those related to specific security issues observed through research into IoT devices, with the aim of making it easier to address these vulnerabilities IoT devices may be deployed at scale on dedicated networks, and these recommendations will be useful to network security teams in mitigating vulnerabilities, especially where device behavior cannot be changed Manufacturers may use standard software distributions aimed at IoT devices without considering DNS behavior. This BCP provides recommendations that can be used as part of the criteria to evaluate these distributions IoT devices typically perform the same set of DNS queries on start-up, which makes them both more vulnerable because of this predictable behavior and also more prone to fingerprinting DNS terminology in this draft conforms to RFC 9499. In this context, Stub Resolver refers to the IoT device, and Resolver refers to the DNS server used by the IoT device. The BCP is primarily concerned with device-to-cloud communication , but DNS may be used in other IoT device communication patterns. Hence recommendations would apply to any deployment type where DNS is used, but decisions on implementation may be proportionate to security risks and operational considerations. For example the implementation of {#configuring-resolvers} and would be appropriate to any implementation, where as may not be proportionate in industrial automation environments where devices do not encrypt other types of traffic .

Conventions and Definitions 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.

Recommendations for IoT Device Stub Resolvers

Configuration of DNS servers used by IoT Stub Resolvers IoT devices have been observed to fall back to hard-coded IP addresses for DNS resolvers, such as well-known open resolvers, or ignore addresses assigned to them via automated configuration methods such as DHCP Option 6. This may result in an insecure communication channel, and the open resolvers used in these hard-coded configurations may be blocked by network policy, preventing the device from working. DNS resolvers on devices MUST be configurable via network configuration protocols. Stub resolvers MUST NOT fall back to hard-coded resolvers. Devices SHOULD use the following priority order for selecting a resolver. The first one that results in a discovered service should be selected. Manual user configuration Device management software IPv6 Router Advertisement (RA) , DHCPv6 (if M=1 bit in RA), IPv4 DHCP . When Encrypted resolver options are present in DHCP and IPv6 Router Advertisements , then they SHOULD be used. If the selected resolver is a plain IP address (e.g. from option 3) this implies unencrypted DNS. In such cases Discovery of Designated Resolvers SHOULD be performed to upgrade to encrypted access, where available.

Source Port and Transaction ID Randomization Some IoT devices have been observed to have insufficient or no randomization in the source ports of DNS queries or DNS transaction IDs. This leaves them vulnerable to spoofed responses. A combination of Source Port and Transaction ID is used, amongst other criteria, by the stub resolver when accepting a DNS response. IoT devices MUST undergo adequate Source Port and Transaction ID randomization in their DNS queries as a mitigation against cache poisoning from spoofed responses. Having both of these values correctly randomized decreases the chances of a successful spoofed attack. Stub resolvers MUST follow the recommendations of as described in Section 4.5 to ensure Source Port randomization and Transaction ID randomization as required by .

Handling of TTL Values IoT devices have been observed making unexpectedly high numbers of DNS queries even when DNS record Time-To-Live values (TTLs) would mean this should be unnecessary. Devices have also been observed issuing DNS queries at fixed, highly predictable intervals for the same domain names, regardless of operational changes or TTL values. Unnecessary queries may lead to a drain of power in resource-constrained IoT devices. Conversely, very high TTLs may impact device operations such as communicating with management servers, receiving software updates, or other changes, which may lead to security issues. Deterministic querying behavior increases the risk of device fingerprinting by adversaries who can profile query timing to identify specific device models or firmware versions. The ideal operational scenario is for the owners of the authoritative zones used to manage the devices setting TTL values appropriately for the zones and specific records within them. Devices would then query these records only as needed. IoT devices MUST cache DNS responses and SHOULD honour TTLs when caching. If for operational reasons this is not ideal, such as the case where a management server record could be cached for an extended period preventing failover or change, then minimum and maximum TTLs MAY be configurable on the device but MUST NOT not be hardcoded values. Where IoT stub resolvers cannot be configured with minimum and maximum TTL values, this can be mitigated by setting these on the network resolver. If certain device operational requirements necessitate periodic revalidation of critical domains (e.g. management servers), these repeated queries SHOULD use non-deterministic inter-query timing to avoid fixed intervals. In case of unsuccessful resolution, such as when the resolver is unavailable, IoT devices should implement exponential back-off strategies.

Support of EDNS(0) Devices have been observed having limited support for EDNS(0), causing them to revert to TCP for queries over 512 bytes, affecting the device's efficiency. Other research findings include consuming additional processing resources and failing to maintain their network connectivity when responses to DNS requests exceed 512 bytes. IoT devices MUST support EDNS(0) and send a supported UDP packet size via OPT 41 . To avoid fragmentation of UDP packets, which may be dropped by intervening networks, the maximum packet size SHOULD be set to 1220 bytes as a default, although device configuration MAY allow this to be configurable. Although the networks to which IoT devices connect may support larger packet sizes than 1220 bytes, the nature of these devices in being deployed on many network types and DNS queries traversing networks controlled by different operators means it is operationally more effective to use this value. In addition, IoT devices MUST support using TCP for queries when a TC bit is returned from the resolver .

Improve Device Behavior in Response to Resolution Problems When resolving domain names, IoT devices may be unable to obtain an answer, and as a result, surges in the number of queries and retries have been observed, or an increase in queries using an alternate protocol (more aggressively querying via IPv6 rather than IPv4). The use of serve-stale by resolver software on the IoT device may mitigate the impact of failed resolution, such as when authoritative servers are unavailable. If the stub-resolver has this capability, device manufacturers should consider the benefits and any impact of using this.

Compliance with Encrypted DNS Standards The majority of IoT devices use unencrypted DNS over port 53, which means this traffic can be captured and is open to interception and manipulation. Encrypted DNS protocols are not mandated for compliance with DNS standards, but the use of encrypted DNS may be mandated by some regulators and advised by competent authorities in deployment guidelines. Encrypted DNS support is widely deployed and it is possible for IoT devices to discover DNS resolver support for this as described in . IoT devices SHOULD support encrypted DNS protocols such as DNS over TLS (DoT) , DNS over QUIC (DoQ) , or DNS over HTTPS (DoH) for enhanced privacy, security, and compatibility. To mitigate against fingerprinting IoT devices, DNS queries can be padded as detailed in and .

Use of DNSSEC IoT devices can be induced to contact an adversary server or make large volumes of DNS queries via spoofed responses to queries. It would be difficult for manufacturers to mitigate this by implementing checks of data received via DNS queries, such as validating IP addresses in the A/AAAA record RDATA. In addition, any validation of this type does not address the problem of MiTM attacks that could be the attack vector. Devices MAY improve security in their DNS stacks by utilizing DNSSEC validation . Where the stub resolver is not capable of DNSSEC validation, but does support checking that queries are validated, the resolver used by the device as described in MUST be configured to validate responses. Manufacturers should consider the type of network the device is likely to be deployed on, such as a home network vs. other types, in determining the likelihood of DNSSEC being available on the network and thus deciding if the device should rely on a validating resolver or making the device independently capable of validation. Manufacturers MUST sign public zones used for device management and services to ensure queries can be validated to support any of their stub-resolvers or more generally resolvers that will use DNSSEC for validation. This will improve security regardless of whether devices can support checking that queries are validated. IoT stub-resolvers may adopt one of two models for validation: - Resolver validation - stub-resolvers using the Authenticated Data (AD) bit, which is suitable for constrained devices but requires explicit trust in the upstream resolver - Full validation - local cryptographic checks, providing stronger assurance Both models improve security over unvalidated queries, but manufacturers should weigh the security considerations, such as trust assumptions, against the operational feasibility when considering which approach to take.

Resolver Validation Where a manufacturer does utilize DNSSEC validation on the device the minimum implementation, from a device perspective, will be a validating resolver and the device supporting the AD bit. Relying solely on the AD bit assumes that the upstream resolver is trustworthy and uncompromised. Manufacturers may implement a testing mechanism to determine if the network resolver supports DNSSEC so that it can utilize validation in a network that supports it, or fall back to unvalidated queries. Any test of the resolver will only validate that it supports DNSSEC, given that the resolver is performing the validation it must be explicitly trusted. In order to check that a DNS query has been validated a stub-resolver MUST check the Authenticated Data (AD) bit in responses to determine whether data was validated by the resolver it is using. When checking for the AD bit stub-resolvers MUST treat DNSSEC validation failures as fatal. Responses that fail validation MUST NOT be used for name resolution.

Full Validation Device stub-resolvers can perform validation themselves in cases where the network resolver does not validate queries or the device does not trust the network resolver to do so. Considerations for device manufacturers in implementing full validation include: Devices performing local validation gain end-to-end trust but at higher computational cost Devices should cache results including intermediate validation results to reduce repeated computation Devices will need to be shipped with a root trust anchor and have a mechanism to securely update this To implement full local validation stub-resolvers MUST conform to section 4.9. In practice it is likely to be easier for manufacturers to implement a minimum footprint validating recursive server on the device, configured to forward queries to a network resolver if necessary, rather than develop this capability in any stub resolver.

Recommendations for Network Operators Most IoT devices do not have specific security software agents installed on them, as is typically the case with general-purpose operating systems, and supply chain vulnerabilities may mean that these devices are compromised before reaching the consumer. Network operators can use DNS resolvers to mitigate these risks. As some aspects of DNS security rely on the stub-resolver, resolver, and authoritative server resolution process and record types (notably DNSSEC), it is also necessary for network operators to implement DNS in such a way as to support some of the recommendations in .

Resolvers Supporting DNSSEC As described in resolvers should be configured to validate DNS responses using DNSSEC.

Blocking of Unmanaged or Malicious DNS Traffic Private network operators may block DNS traffic to any resolvers other than those managed by the operator, so that traffic is not bypassing any DNS security controls such as response policy zones or DNS traffic logging. This is more likely to be the case on enterprise or other private networks rather than service providers that don't want to limit customers using alternate resolvers. Where operators have networks dedicated to IoT devices, they MAY limit DNS resolution to only domain names used by those IoT devices to mitigate any impact in the event of a compromise to the device. Manufacturers SHOULD provide domain names used for communication to facilitate this and other security measures used to secure devices and identify those that are compromised. Manufacturer Usage Descriptions (MUDs) can provide details of domain names used in device operations that can then be added to DNS security controls.

Availability Providers SHOULD alter resolver configuration to mitigate some of the security risks or operational issues identified in this BCP where it does not impact the operation of other types of DNS clients. Network operators SHOULD configure DNS resolvers to use serve-stale for networks supporting IoT devices, especially where these networks are dedicated to this type of device, to limit any operational impact on IoT devices when resolution fails. Network operators MUST support IoT devices with dual-stack resolvers, rather than providing only IPv4 resolvers when devices are configured with both IPv4 and IPv6. DNS queries are most commonly carried over UDP and compromised devices have been used in DoS attacks by sending queries with forged source addresses, hence network operators MUST implement network ingress filtering. Network operators should implement DNS Response Rate Limiting (RRL) on resolvers to mitigate high query volumes from devices causing DoS to the DNS infrastructure.

Recommendations for Manufacturer Authoritative DNS Zones

Zone Signing Zones supporting the management and data collection of devices MUST be DNSSEC signed in order to support the behavior described in and . The zones used for these purposes SHOULD be publicly listed for network operators to use in securing their networks as described in .

TTL Values As stated in manufacturers MUST consider setting TTL values for management zone records that are appropriate for device operations, considering a balance between devices performing excess queries, continuous operation in the event of resolvers being unreachable, and the potential for changes in RDATA such as management IP addresses.

Security Considerations This document does not include protocol changes so there are no specific security considerations in this draft related to new protocol implementations, rather the BCP focusses on security improvements by implementing existing protocols as in the sections above.

IANA Considerations This document has no IANA actions.

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. The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK] 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. 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. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice. This document offers guidance to engineers designing Internet- connected smart objects. This document defines the use of cipher suites for TLS 1.3 based on Hashed Message Authentication Code (HMAC). Using these cipher suites provides server and, optionally, mutual authentication and data authenticity, but not data confidentiality. Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication. This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced-security mechanism that provides authentication and message integrity without supporting confidentiality. This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK] This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known. This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days. 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 describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. 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 specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets. RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

Acknowledgments We thank the researchers, reviewers, and engineers who contributed to the analysis and testing process. The authors thank Mohamed Boucadair, Chris Box, Eliot Lear, Martine Sophie Lenders, Jim Reid, Michael Richardson and Hannes Tschofenig for their contributions, questions and comments.