IoT DNS Security and Privacy Guidelines
draft-ietf-iotops-iot-dns-guidelines-04

iotops                                                         A. Mishra
Internet-Draft                                                     Inria
Intended status: Best Current Practice                          A. Losty
Expires: 7 January 2027                                  A. M. Mandalari
                                                                     UCL
                                                               J. Mozley
                                                                Infoblox
                                                               M. Cunche
                                                       INSA-Lyon & Inria
                                                             6 July 2026

                IoT DNS Security and Privacy Guidelines
                draft-ietf-iotops-iot-dns-guidelines-04

Abstract

   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.

About This Document

   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.

Mishra, et al.           Expires 7 January 2027                 [Page 1]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

Status of This Memo

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

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Guidance for IoT Device Manufacturers . . . . . . . . . . . .   4
     3.1.  Configuration of DNS servers used by IoT Stub
           Resolvers . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Source Port and Transaction ID Randomization  . . . . . .   5
     3.3.  Handling of TTL Values  . . . . . . . . . . . . . . . . .   6
     3.4.  Support of EDNS(0)  . . . . . . . . . . . . . . . . . . .   6
     3.5.  Improve Device Behavior in Response to Resolution
           Problems  . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.6.  Compliance with Encrypted DNS Standards . . . . . . . . .   7
     3.7.  Use of DNSSEC . . . . . . . . . . . . . . . . . . . . . .   8
       3.7.1.  Stub-resolver Checking for Validation . . . . . . . .   9
       3.7.2.  Stub-resolver Performing Full Validation  . . . . . .  10
   4.  Guidance for Manufacturer Authoritative DNS Zones . . . . . .  10

Mishra, et al.           Expires 7 January 2027                 [Page 2]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

     4.1.  Zone Signing  . . . . . . . . . . . . . . . . . . . . . .  11
     4.2.  TTL Values  . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Guidance for Network Operators  . . . . . . . . . . . . . . .  11
     5.1.  Resolvers Supporting DNSSEC . . . . . . . . . . . . . . .  11
     5.2.  Blocking of Unmanaged or Malicious DNS Traffic  . . . . .  12
     5.3.  Availability  . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   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

Mishra, et al.           Expires 7 January 2027                 [Page 3]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

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

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Guidance for IoT Device Manufacturers

   The following guidance specifies expected behavior for IoT device
   stub resolvers to ensure secure, privacy-preserving, and
   operationally efficient DNS resolution.

Mishra, et al.           Expires 7 January 2027                 [Page 4]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

3.1.  Configuration of DNS servers used by IoT Stub Resolvers

   IoT devices have been observed to fall back to hard-coded IP
   addresses for DNS resolvers, such as well-known open resolvers, or
   ignore addresses assigned to them via automated configuration methods
   such as DHCP Option 6.  This may result in an insecure communication
   channel, and the open resolvers used in these hard-coded
   configurations may be blocked by network policy, preventing the
   device from 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.

   1.  Manual user configuration

   2.  Device management software authorized for configuration purposes

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

3.2.  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 SHOULD be consistent with Sections 4.5 and 9.2 of
   [RFC5452].  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 SHOULD use multiple source
   ports when multiple DNS queries are outstanding.

Mishra, et al.           Expires 7 January 2027                 [Page 5]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

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

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

Mishra, et al.           Expires 7 January 2027                 [Page 6]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

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

3.5.  Improve Device Behavior in Response to Resolution Problems

   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.

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

Mishra, et al.           Expires 7 January 2027                 [Page 7]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

   IoT devices SHOULD support at least one encrypted DNS transport, such
   as DNS over TLS (DoT) [RFC7858], DNS over QUIC (DoQ) [RFC9250], or
   DNS over HTTPS (DoH) [RFC8484], 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.  To mitigate against
   fingerprinting of IoT devices, DNS queries MAY be padded as detailed
   in [RFC7830] and [RFC8467].

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

Mishra, et al.           Expires 7 January 2027                 [Page 8]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

   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 |  CD |  Resolver  |   DNSSEC  | Notes                       |
   | Bit | Bit | Validated? |    RRs    |                             |
   |     |     |            | Returned? |                             |
   +=====+=====+============+===========+=============================+
   |  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.                 |
   +-----+-----+------------+-----------+-----------------------------+

                Table 1: Stub-resolver deployment options

3.7.1.  Stub-resolver Checking for Validation

   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.

Mishra, et al.           Expires 7 January 2027                 [Page 9]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

   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.

3.7.2.  Stub-resolver Performing Full Validation

   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

   IoT devices that perform local DNSSEC validation MUST conform to the
   applicable DNSSEC validation requirements in [RFC4035].
   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
   for provisioning and updating them.  Manufacturers SHOULD support
   automated trust-anchor updates as described in [RFC5011] and SHOULD
   account for changes to DNSSEC cryptographic algorithms.

4.  Guidance for Manufacturer Authoritative DNS Zones

   Manufacturers use public authoritative DNS zones for purposes such as
   device configuration, control and upgrades.

Mishra, et al.           Expires 7 January 2027                [Page 10]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

4.1.  Zone Signing

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

4.2.  TTL Values

   As stated in Section 3.3 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.

5.  Guidance for Network Operators

   Most IoT devices do not have specific security software agents
   installed on them, as is typically the case with general-purpose
   operating systems, and supply chain vulnerabilities may mean that
   these devices are compromised before reaching the consumer.  Network
   operators can use DNS resolvers to mitigate these risks, 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.

5.1.  Resolvers Supporting DNSSEC

   In order to support improving device DNS security as described in
   Section 3.7 resolvers SHOULD be configured to validate DNS responses
   using DNSSEC.

Mishra, et al.           Expires 7 January 2027                [Page 11]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

5.2.  Blocking of Unmanaged or Malicious DNS Traffic

   Private network operators may block DNS traffic to any resolvers
   other than those managed by the operator, so that traffic is not
   bypassing any DNS security controls such as response policy zones or
   DNS traffic logging.  This is more likely to be the case on
   enterprise or other private networks rather than service providers
   that don't want to limit customers using alternate resolvers.

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

   Manufacturers SHOULD provide 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.

   Manufacturer Usage Descriptions (MUDs) can provide information about
   domain names used in device operations and can support the deployment
   of DNS-based security controls.

   Manufacturers SHOULD update this information when device dependencies
   change so that device operations are not impacted.

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

Mishra, et al.           Expires 7 January 2027                [Page 12]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

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

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

7.  IANA Considerations

   This document has no IANA actions.

8.  References

8.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Mishra, et al.           Expires 7 January 2027                [Page 13]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/rfc/rfc2827>.

   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
              Resilient against Forged Answers", RFC 5452,
              DOI 10.17487/RFC5452, January 2009,
              <https://www.rfc-editor.org/rfc/rfc5452>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/rfc/rfc6891>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9715]  Fujiwara, K. and P. Vixie, "IP Fragmentation Avoidance in
              DNS over UDP", RFC 9715, DOI 10.17487/RFC9715, January
              2025, <https://www.rfc-editor.org/rfc/rfc9715>.

8.2.  Informative References

   [ENISAGuidanceForNIS2]
              "NIS2 Technical Implementation Guidance", n.d.,
              <https://www.enisa.europa.eu/publications/nis2-technical-
              implementation-guidance>.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2132>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4035>.

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
              September 2007, <https://www.rfc-editor.org/rfc/rfc5011>.

   [RFC7452]  Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
              "Architectural Considerations in Smart Object Networking",
              RFC 7452, DOI 10.17487/RFC7452, March 2015,
              <https://www.rfc-editor.org/rfc/rfc7452>.

Mishra, et al.           Expires 7 January 2027                [Page 14]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

   [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
              DOI 10.17487/RFC7830, May 2016,
              <https://www.rfc-editor.org/rfc/rfc7830>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/rfc/rfc7858>.

   [RFC8106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 8106, DOI 10.17487/RFC8106, March 2017,
              <https://www.rfc-editor.org/rfc/rfc8106>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/rfc/rfc8415>.

   [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms
              for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
              October 2018, <https://www.rfc-editor.org/rfc/rfc8467>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

   [RFC8767]  Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
              to Improve DNS Resiliency", RFC 8767,
              DOI 10.17487/RFC8767, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8767>.

   [RFC9150]  Cam-Winget, N. and J. Visoky, "TLS 1.3 Authentication and
              Integrity-Only Cipher Suites", RFC 9150,
              DOI 10.17487/RFC9150, April 2022,
              <https://www.rfc-editor.org/rfc/rfc9150>.

   [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
              Dedicated QUIC Connections", RFC 9250,
              DOI 10.17487/RFC9250, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9250>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/rfc/rfc9364>.

Mishra, et al.           Expires 7 January 2027                [Page 15]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

   [RFC9462]  Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
              Jensen, "Discovery of Designated Resolvers", RFC 9462,
              DOI 10.17487/RFC9462, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9462>.

   [RFC9463]  Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
              and T. Jensen, "DHCP and Router Advertisement Options for
              the Discovery of Network-designated Resolvers (DNR)",
              RFC 9463, DOI 10.17487/RFC9463, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9463>.

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9499>.

   [RFC9520]  Wessels, D., Carroll, W., and M. Thomas, "Negative Caching
              of DNS Resolution Failures", RFC 9520,
              DOI 10.17487/RFC9520, December 2023,
              <https://www.rfc-editor.org/rfc/rfc9520>.

   [UCLandInriaPaper]
              "From Lookup to Lockdown DNS Guidelines for Securing IoT
              Ecosystems", n.d.,
              <https://discovery.ucl.ac.uk/id/eprint/10223583/>.

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, Martine Sophie Lenders, Jim Reid, Michael Richardson and Hannes
   Tschofenig for their contributions, questions and comments.

Authors' Addresses

   Abhishek Mishra
   Inria
   Email: abhishek.mishra@inria.fr

   Andrew Losty
   UCL
   Email: andrew.losty.23@ucl.ac.uk

   Anna Maria Mandalari
   UCL

Mishra, et al.           Expires 7 January 2027                [Page 16]
Internet-Draft             IoT-DNS-Guidelines                  July 2026

   Email: a.mandalari@ucl.ac.uk

   Jim Mozley
   Infoblox
   Email: jmozley@infoblox.com

   Mathieu Cunche
   INSA-Lyon & Inria
   Email: mathieu.cunche@inria.fr

Mishra, et al.           Expires 7 January 2027                [Page 17]