| Internet-Draft | IoT-DNS-Guidelines | May 2026 |
| Mishra, et al. | Expires 9 November 2026 | [Page] |
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.¶
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-ietf-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 9 November 2026.¶
Copyright (c) 2026 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 [UCLandInriaPaper] 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.¶
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 end point 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, and these recommendations will be useful to network security teams in mitigating vulnerabilities, especially where device behavior cannot be changed post-deployment¶
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 [RFC7452], 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 {#configuring-resolvers} and Section 3.2 would be appropriate to any implementation, whereas Section 3.6 may not be proportionate in industrial automation environments where devices do not encrypt other types of traffic [RFC9150].¶
DNS terminology in this document conforms to [RFC9499]. 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 following guidance specifies expected behavior for IoT device stub resolvers to ensure secure, privacy-preserving, and operationally efficient DNS resolution.¶
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 functioning correctly.¶
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 valid DNS response SHOULD be selected.¶
Manual user configuration¶
Device management software¶
IPv6 Router Advertisement (RA) [RFC8106], DHCPv6 [RFC8415] (if M=1 bit in RA), IPv4 DHCP [RFC2132]. When encrypted resolver options are present in DHCP and IPv6 Router Advertisements [RFC9463], 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 (DDR) [RFC9462] SHOULD be performed to upgrade to encrypted access, where available.¶
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.¶
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.¶
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 so as 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 devices MUST cache DNS responses and SHOULD honor TTLs when caching. If for operational reasons this is not ideal, then minimum and maximum TTLs MAY be configurable on the device but MUST NOT be hardcoded values. Where 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 fixed intervals 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 Section 3.5.¶
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 [RFC6891]. To avoid fragmentation of UDP packets, which may be dropped by intervening networks, manufacturers MUST follow guidance in [RFC9715], 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 [RFC1035].¶
When resolving domain names, IoT devices may not receive a response from a resolver. 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).¶
Device software MUST implement DNS resolution algorithms that bound the number and rate of queries sent from the device stub resolver to its configured resolvers. This will be implementation specific, but manufacturers should consider implementing the recommendations for resolvers detailed in [RFC9520] section 3.2 which recommends the caching of resolution failures for at least 1 second.¶
If supported by the stub-resolver implementation on device operating systems the use of serve-stale [RFC8767] 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.¶
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 [ENISAGuidanceForNIS2] 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 Section 3.1.¶
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]. 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. To mitigate against fingerprinting of IoT devices, DNS queries can be padded as detailed in [RFC7830] and [RFC8467].¶
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 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 [RFC9364] on the stub resolver. When supported, devices typically follow one of two models for validation (see Table 1) 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. |
Where a manufacturer does utilize 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 queries. 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.¶
In order to check that a DNS query has been validated a stub resolver MUST check the Authenticated Data (AD) bit [RFC4035] 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.¶
A device stub resolver can perform validation itself 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 validation outcomes to reduce repeated computation¶
Devices 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 [RFC4035] 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 the network resolver(s), rather than develop this capability in any stub resolver.¶
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, 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.¶
Manufacturers should be aware of network operator DNS deployment options as devices will use these resolvers, even though this infrastructure is not under manufacturer's control.¶
As 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 also necessary for network operators to implement DNS in such a way as to support some of the recommendations in Section 3.¶
In order to support improving device DNS security as described in Section 3.7 resolvers SHOULD be configured to validate DNS responses using DNSSEC.¶
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.¶
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 [RFC8767]. This is particularly recommended in environments dedicated to supporting IoT devices, in order to minimize operational disruption during DNS resolution failures. Furthermore, network operators MUST provide dual-stack DNS resolvers for IoT devices configured with both IPv4 and IPv6 connectivity, rather than limiting resolver support to IPv4 only.¶
DNS queries are most commonly transported over UDP, and compromised devices have been used in DoS attacks by sending queries with forged source addresses. Therefore, 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 attacks against DNS infrastructure.¶
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, or 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.¶
This document has no IANA actions.¶
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, Martine Sophie Lenders, Jim Reid, Michael Richardson and Hannes Tschofenig for their contributions, questions and comments.¶