| Internet-Draft | IoT-DNS-Guidelines | July 2025 |
| Mishra, et al. | Expires 21 January 2026 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://miishra.github.io/IoT-DNS-Guidelines/draft-mishra-iotops-iot-dns-guidelines-latest.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mishra-iotops-iot-dns-guidelines/.¶
Source for this draft and an issue tracker can be found at https://github.com/miishra/IoT-DNS-Guidelines.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
IoT devices SHOULD support encrypted DNS protocols such as DNS over TLS (DoT) [RFC7858], DNS over QUIC (DoQ) [RFC9250], or DNS over HTTPS (DoH) [RFC8484] for enhanced privacy, security, and compatibility. To mitigate against fingerprinting IoT devices, DNS queries can be padded as detailed in [RFC7830] and [RFC8467]. 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.¶
IoT devices have been observed to fall back to hard-coded IP addresses for DNS resolvers or ignore addresses assigned to them via automated configuration methods such as DHCP Option 6, potentially bypassing network security mechanisms or giving rise to operational issues.¶
DNS resolvers on devices MUST be configurable via network configuration protocols such as DHCP [RFC2132] and [RFC8415], IPv6 Router Advertisement (RA) options [RFC8106], Discovery of Designated Resolvers [RFC9462], device management software, or manual configuration. Stub resolvers MUST NOT fall back to hard-coded resolvers. 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.¶
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 [RFC5452] as described in Section 4.5 to ensure Source Port randomization and Transaction ID randomization as required by [RFC1035].¶
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.¶
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 [RFC6891]. 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 [RFC1035].¶
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 [RFC8767] 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. 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.¶
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 integrate robustness in their DNS stacks by utilizing DNSSEC validation [RFC9364]. Where the stub resolver is not capable of DNSSEC validation, or it is not operationally advisable for reasons such as power consumption, the resolver SHOULD 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 making the device independently capable of validation rather than relying on a resolver. Manufacturers SHOULD sign public zones used for device management and services to ensure queries can be validated as a mitigation against spoofed responses. For privacy reasons, resolvers SHOULD be configured to copy the root DNS zone [RFC8806] as this will prevent leakage of private queries and also provides operational efficiency improvements.¶
This BCP discusses security considerations for IoT devices in section Recommendations for IoT Device Stub Resolvers and mitigations that can be implemented on DNS resolvers. More general DNS security considerations in managing networks with IoT devices are detailed here.¶
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.¶
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.¶
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. For instance the use of serve-stale [RFC8767] is likely to benefit all stub resolvers on a network.¶
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) could provide details of domain names used in device operations that can then be added to DNS security controls.¶
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 [RFC2827] 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.¶
This document has no IANA actions.¶
We thank the researchers, reviewers, and engineers who contributed to the analysis and testing process.¶