IoT DNS Security and Privacy Guidelines

Recommendations for IoT Device Stub Resolvers

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. 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 . 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.

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 or ignore addresses assigned to them via automated configuration methods such as DHCP Option 6. DNS resolvers on devices MUST be configurable via network configuration protocols. 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. 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 , then they SHOULD be used. If the selected resolver is a plain IP address (e.g. from options 4 or 5) 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. 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.

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 section <<configuring-resolvers>> 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.

Security Considerations 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 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 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.