]> Inria

abhishek.mishra@inria.fr

UCL

andrew.losty.23@ucl.ac.uk

UCL

a.mandalari@ucl.ac.uk

Infoblox

jmozley@infoblox.com

INSA-Lyon & Inria

mathieu.cunche@inria.fr

ops iotops This document outlines guidance for Internet of Things (IoT) manufacturers regarding the implementation of DNS stub resolver software on devices, and for the management zones used for purposes such as device configuration and software upgrades. It aims to mitigate security threats, enhance privacy, and to address operational security challenges. DNS resolution between devices and management zone servers depends upon DNS services within operator networks, and these services and operator networks can be impacted by device behavior. Hence, this document also provides guidance to network operators that deploy IoT devices to mitigate the specific risks identified in this document and take advantage of improved DNS security mechanisms provided by manufacturers. 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. This document provides DNS guidance across the IoT resolution path (device, resolver, and authoritative infrastructure), with primary emphasis on device behavior aimed at IoT manufacturers. The recommendations in this document are organized according to three roles: (1) IoT device manufacturers, concerning DNS functionality implemented on devices; (2) operators of authoritative DNS zones used for device management and related services; and (3) network operators providing recursive DNS resolution or DNS-based security controls to IoT devices. Sections , , and address these roles, respectively. While the guidance in this document may apply to any device using DNS, this document considers 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 on device functionality IoT devices do not typically have endpoint security agents installed on them that are widely used on general-purpose operating systems There are many DNS RFCs, and this document 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 where device behavior cannot be changed post-deployment, making these recommendations particularly useful to network security teams in mitigating vulnerabilities Manufacturers may use standard software distributions aimed at IoT devices without considering DNS behavior, and the guidelines here 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 network fingerprinting This document is primarily concerned with device-to-cloud communication , but DNS may be used in other IoT device communication patterns. Hence recommendations apply to any deployment type where DNS is used, but decisions on implementation will be proportionate to the associated security risks and operational considerations. For example, the implementation of and would be appropriate to any implementation, whereas may not be proportionate in industrial automation environments where devices do not encrypt other types of traffic . Multicast DNS (mDNS) is a distinct protocol from unicast DNS and is out of scope in these recommendations.

Threat Summary Threats and associated mitigations are summarized in the table below, along with a link to the relevant sections. Threat Mitigation Summary Section Hard-coded or ignored DNS resolver configuration Use configurable resolvers; do not fall back to hard-coded resolvers Predictable source ports or transaction IDs Use unpredictable transaction IDs across the full 16-bit range and ensure source ports are random and span a large a range as practical, using different source ports for concurrent queries Excessive or fixed-interval queries that ignore TTLs Honor TTLs; cache responses where resources permit; avoid deterministic revalidation intervals Poor EDNS(0) support or oversized DNS/UDP messages Support EDNS(0); advertise safe UDP payload sizes to avoid fragmentation; retry over TCP when the TC bit is set Retry storms following resolution failures Bound query retries; cache resolution failures; use serve-stale where applicable Unencrypted DNS traffic Support an appropriate protected DNS transport, such as DoT, DoQ, DoH, or protected DoC, where feasible Spoofed DNS responses or AiTM redirection DNSSEC-sign manufacturer-operated management zones; rely on validation by a trusted resolver or perform local DNSSEC validation , Compromised devices used for DoS with forged source addresses Implement ingress filtering; use DNS Response Rate Limiting (RRL) where appropriate

Terminology DNS terminology in this document conforms to . Terminology Description AiTM adversary-in-the-middle attacks DoS Denial of Service Stub Resolver DNS resolver functionality on an IoT device that relies on an upstream recursive resolver. IoT devices addressed by this document are assumed to operate as stub resolvers, or local resolver components that rely on an upstream recursive resolver. IoT devices operating as full recursive resolvers are out of scope for this document. Resolver The recursive DNS resolver used by the IoT device Management zone A DNS zone operated by an entity, hosting its devices' and management servers' records

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.

Guidance for IoT Device Manufacturers An IoT device may implement DNS resolution using a stub resolver, a validating stub resolver, or another suitable local resolver component. This document does not require IoT devices to use a particular resolver architecture. Unless otherwise stated, the recommendations in this section apply to DNS stub resolver functionality implemented on the device. The following guidance specifies expected behavior for IoT device stub resolvers to ensure secure, privacy-preserving, and operationally efficient DNS resolution.

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 . Such behavior can bypass network DNS policies and can prevent devices from functioning correctly when the hard-coded resolver is unreachable or blocked by the network. The DNS resolver configuration used by an IoT device MUST be configurable through applicable network configuration protocols or authorized device-management mechanisms. Devices MUST NOT fall back to hard-coded public resolvers. Devices SHOULD use the following priority order for selecting a resolver. The first one that results in a valid DNS response SHOULD be selected. Manual user configuration Device management software authorized for configuration purposes IPv6 Router Advertisement (RA) , DHCPv6 using DNS configuration options such as those defined in , and IPv4 DHCP . When encrypted resolver options are present in DHCP or IPv6 Router Advertisements , they SHOULD be used. If the selected resolver is identified only by an IP address and encrypted resolver information was not otherwise provided, Discovery of Designated Resolvers (DDR) MAY be performed to discover an encrypted resolver, 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, making 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. Device behavior MUST be consistent with Sections 4.5 and 9.2 of . Stub resolvers sending DNS queries over UDP MUST use unpredictable DNS transaction IDs across the full 16-bit range and unpredictable source ports selected from as large a range of available ports as is practical. They MUST use multiple source ports when multiple DNS queries are outstanding.

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 query behavior that ignores TTL values increases the risk of device fingerprinting by adversaries who can profile query timing to identify specific device models or firmware versions. Manufacturers MUST configure the records in authoritative zones with TTL values appropriate to the use of the records by devices, ensuring the TTL is not too low to cause unnecessary queries for frequently used names, but not high enough to cause operational issues, such as when the IP address of an A record in a management zone changes. IoT device resolver implementations SHOULD cache positive DNS responses when sufficient memory and other device resources are available. Implementations that cache DNS resource records MUST expire, or otherwise process cached records in accordance with their TTLs. Where minimum or maximum cache TTL values are supported, these values SHOULD be configurable through an appropriate device-management mechanism rather than fixed by the implementation. When device stub resolvers cannot be configured with minimum and maximum TTL values, this MAY 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 predictable timing patterns that could enable traffic fingerprinting. In the event of resolution failure (e.g., no response from the resolver), devices SHOULD implement back-off strategies to limit unnecessary query traffic; also see .

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 increased processing overhead and devices 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, manufacturers MUST follow guidance in , although device configuration MAY allow this to be configurable. Although the networks to which IoT devices connect may support larger packet sizes, 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 a smaller size that avoids fragmentation. In addition, IoT devices MUST support using both TCP and UDP for queries, and support switching to TCP when a TC bit is returned from the resolver . For constrained networks where DNS messages may exceed the available link-layer frame size, implementations SHOULD also consider DNS over CoAP as described in .

Improve Device Behavior in Response to Resolution Problems When resolving domain names, IoT devices may not receive a response from a resolver. This can result in surges in DNS queries and retries, or increased use of an alternative protocol (e.g., querying over IPv6 more frequently than over IPv4). Device resolver implementations MUST comply with the retry and resolution-failure caching requirements in Section 3.2 of . In particular, a resolver MUST NOT retry a given query to the same server address over the same DNS transport more than twice before considering that server address unresponsive for the query, and MUST cache resolution failures for at least one second. Implementations SHOULD limit the memory and processing resources allocated to the resolution-failure cache. If supported by the stub-resolver implementation on device operating systems, the use of serve-stale on the IoT device may mitigate the impact of failed resolution, such as when authoritative servers are unavailable. This will reduce the impact of surges in DNS traffic if the network resolver is unreachable, and it may allow the device to maintain ongoing communication with endpoints for which previously valid DNS data remain usable.

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 at least one encrypted DNS transport, such as DNS over TLS (DoT) , DNS over QUIC (DoQ) , or DNS over HTTPS (DoH) , when doing so is feasible and does not impair device operation because of power, memory, computational, or other deployment constraints. This enhances privacy by preventing passive observation of DNS queries, improves security by mitigating adversary-in-the-middle (AiTM) attacks, and enables compatibility with resolvers that require encrypted transport. When encrypted DNS is used, devices SHOULD use EDNS(0) padding as described in and to reduce size-based traffic fingerprinting, where doing so does not cause excessive fragmentation, energy consumption, or other operational costs. Padding policies suitable for conventional networks may be inappropriate on constrained links with small frame sizes.

Use of DNSSEC IoT devices can be induced to connect to an adversary's 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, as this does not reliably prevent malicious redirection. In addition, any validation of this type does not address the problem of AiTM attacks targeting DNS query responses. DNSSEC can be implemented by manufacturers to mitigate AiTM attacks on DNS query responses. Note that manufacturers MUST have signed public zones used for device management and services so that validation can take place. This improves security when devices do not perform local validation, as many network operators deploy validating resolvers. Manufacturers MAY improve device security by utilizing DNSSEC validation on the stub resolver. When supported, devices typically follow one of two models for validation (see ) by setting a combination of the DO and CD bits in DNS queries: Stub-resolver checking for validation - the stub resolver checks for the Authenticated Data (AD) bit in the response, which is suitable for constrained devices but requires explicit trust in the upstream resolver performing correct DNSSEC validation Stub-resolver performing full validation - local cryptographic checks of DNSSEC-related records, 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 determining which approach to adopt. Manufacturers should consider the type of network the device is likely to be deployed on, such as a home network vs. other environments, in determining the likelihood of DNSSEC validation being available on the network and thus deciding if the device should rely on a validating resolver or be independently capable of performing DNSSEC validation. The deployment options are summarised below, with two constituting the typical deployment scenarios: DO Bit CD Bit Resolver Validated? DNSSEC RRs Returned? Notes Y Y N Y Resolver does not validate. DNSSEC data returned. Stub-resolver performing full validation deployment. Y N Y Y Resolver validates. DNSSEC data returned. Stub-resolver can use AD bit to check validation. N Y N N Resolver does not validate. No DNSSEC data returned. Do not use. N N Y N Resolver validates. No DNSSEC data. Stub-resolver checking for validation deployment.

Stub-resolver Checking for Validation Where a manufacturer implements DNSSEC validation on the device, the minimum implementation will be a stub resolver checking the AD bit to see if the answer has been validated. 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, enabling the device to utilize validation when available in a network that supports it, or falls back to unvalidated answers. Any such test of the resolver will only validate that it supports DNSSEC; given that the resolver is performing the validation, it must be explicitly trusted. To determine whether a DNS response 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.

Stub-resolver Performing Full Validation A device stub resolver MAY perform DNSSEC validation locally when the network resolver does not perform validation or when the device does not trust the network resolver to do so. Local validation introduces additional implementation, processing, memory, and trust-anchor-management requirements that manufacturers need to consider for constrained devices. Considerations for device manufacturers in implementing full validation include: Devices performing local validation gain end-to-end trust but at a higher computational cost Devices should cache results, including validation outcomes, to reduce repeated computation Devices need to be shipped with a root trust anchor and have a mechanism to update this securely IoT devices that perform local DNSSEC validation MUST conform to the applicable DNSSEC validation requirements in . Manufacturers MAY implement this functionality in a validating stub resolver, a local validating resolver, or another suitable local resolver component. Devices performing local DNSSEC validation MUST maintain authenticated DNS trust anchors and MUST provide a secure mechanism to provision and update them. Manufacturers SHOULD support automated trust-anchor updates as described in and SHOULD account for changes to DNSSEC cryptographic algorithms. Device software updates MAY include changes to the CA root store to support the TLS used in Encrypted DNS protocols.

DNS over CoAP DNS over CoAP (DoC) provides a DNS transport for constrained IoT environments using CoAP , with confidentiality and integrity provided by (D)TLS or OSCORE . DoC is appropriate where the resource or transport characteristics of constrained devices make DoT, DoH, or DoQ unsuitable. The choice of DNS transport SHOULD consider device resources, available protocol stacks, network characteristics, and operational requirements. Implementations MUST conform to all requirements specified in , these include resolver configuration, request/response matching, caching, retransmission, and security. Implementations MUST additionally follow and where requirements interact with the underlying CoAP transport. Implementations where traffic analysis is a concern SHOULD consider message size, timing, and packet-count characteristics when selecting DoC block sizes, padding, and header-compression mechanisms. Mitigations including block-size selection and final-block padding are discussed in and ; SCHC MAY additionally be used to reduce observable header information.

Publication of Device Domain Dependencies Manufacturers SHOULD provide network operators with accurate and current information about the domain names, domain-name patterns, and external services required for device operation. When providing details of the domains used by a device for network security, manufacturers SHOULD include all such domains, including those outside their direct control, such as content delivery networks or cloud services. This allows network operators to distinguish legitimate device traffic from anomalous or malicious traffic. Manufacturer Usage Descriptions (MUDs) can provide machine-readable information that defines the network communications required for device operation and can support the deployment of network security controls. Manufacturers SHOULD publish device communication requirements, including relevant management domain names, in a publicly retrievable MUD file where applicable, or in comparable manufacturer documentation. Manufacturers SHOULD update this information when device dependencies change so that device operations are not impacted.

Guidance for Manufacturer Authoritative DNS Zones Manufacturers use public authoritative DNS zones for purposes such as device configuration, control, and upgrades. This section covers guidance for manufacturers in operating these 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 configure TTL values for management zone records that are appropriate for device operations, considering a balance between avoiding excessive query traffic, maintaining continuous operation in the event the resolver is unreachable, and accommodating potential changes in RDATA such as management IP addresses.

Guidance for Network Operators This section provides guidance to operators that have IoT devices on their networks. Manufacturers should be aware of the network operator guidance in this section as devices will use these resolvers, even though this infrastructure is not under the manufacturer's control. Most IoT devices do not have dedicated security software agents, as are commonly available for general-purpose operating systems. In addition, supply chain vulnerabilities may result in devices being compromised before they reach the consumer. Network operators can use DNS resolvers to mitigate these risks, although this will vary depending on policy. These networks may be public, without restrictions on DNS usage, or may be private networks that could be dedicated to IoT devices where operators implement more security controls to mitigate these risks. Some aspects of DNS security rely on the resolution process between stub resolver, resolver, and authoritative servers, as well as DNS record types (notably DNSSEC). It is therefore necessary for network operators to implement DNS in such a way as to support some of the recommendations in .

Resolvers Supporting DNSSEC In order to support improving device DNS security 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 resolvers not managed by the operator to prevent bypass of DNS security controls, such as Response Policy Zones (RPZs) and DNS traffic logging. This practice is more common on enterprise and other private networks than on service-provider networks, where operators may avoid restricting customers' use of alternative resolvers. Where operators maintain networks dedicated to IoT devices, they MAY restrict DNS resolution to domain names that are necessary for normal device operation in order to reduce the impact of a device compromise. Network operators MAY use manufacturer-provided domain dependency information, including MUDs , to distinguish legitimate device traffic from anomalous or malicious traffic.

Minimizing DNS Response Size Recursive resolvers serving constrained IoT networks SHOULD minimize unnecessary DNS response data where supported by the resolver implementation. In particular, operators SHOULD use minimal-response configurations that avoid unnecessary Additional-section records while retaining records required for correct DNS resolution and the semantics of the queried RR type . Reducing unnecessary response data can reduce bandwidth usage, processing overhead, energy consumption, and the likelihood of fragmentation on constrained links.

Availability Providers should optimize resolver configurations to mitigate the security and operational risks identified in this document, provided that such optimizations do not adversely affect the operation of other DNS clients. Network operators SHOULD optimize DNS resolver configurations through the use of serve-stale mechanisms, as specified in . This is particularly recommended in environments dedicated to supporting IoT devices, in order to minimize operational disruption during DNS resolution failures. Recursive DNS resolvers provided to IoT devices SHOULD be able to perform dual-stack DNS resolution, consistent with . DNS queries are most commonly transported over UDP, and compromised devices have been used to launch DoS attacks by sending queries with forged source addresses. Therefore, 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 attacks against DNS infrastructure.

Security Considerations IoT devices are often deployed at scale, operate under resource constraints, and typically lack host-based security controls. Consequently, weaknesses in DNS behavior can increase exposure to spoofing, on-path attacks, amplification, and fingerprinting. The recommendations in this document improve the security properties of DNS resolution by promoting correct protocol behavior, reducing unnecessary or anomalous query traffic, and supporting the use of authenticated and integrity-protected data (e.g., DNSSEC) and encrypted transport. The effectiveness of these measures depends on coordinated deployment across stub resolvers, recursive resolvers, and authoritative servers. Partial deployment may reduce the benefits of some mechanisms. Residual risks remain, including device compromise outside the DNS layer, misconfiguration, and reliance on untrusted upstream resolvers. In addition, the use of encrypted DNS may limit network-based inspection and policy enforcement. This document does not introduce new protocols or mechanisms; it reduces the attack surface and improves the predictability and resilience of DNS interactions in IoT environments.

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] 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 widely deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible and signaling the need to upgrade from UDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS. 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 the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data, (2) a response indicating the requested data does not exist, or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type. RFC 2308 specifies requirements for DNS negative caching. There, caching of TYPE 2 responses is mandatory and caching of TYPE 3 responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures. RFC 4035 allows DNSSEC validation failure caching. This document updates RFC 4035 to require caching for DNSSEC validation failures. RFC 4697 prohibits aggressive requerying for NS records at a failed zone's parent zone. This document updates RFC 4697 to expand this requirement to all query types and to all ancestor zones. 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). 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. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. 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. 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. 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 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 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 specifies 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 obsoletes RFC 8415. It incorporates verified errata and obsoletes the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client. 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] This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s). This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK] This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. 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 memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. This document provides guidelines and documents best current practice for operating authoritative DNS servers, recursive resolvers, and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901.

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