



iotops                                                         A. Mishra
Internet-Draft                                                     Inria
Intended status: Best Current Practice                          A. Losty
Expires: 9 November 2026                                 A. M. Mandalari
                                                                     UCL
                                                               J. Mozley
                                                                Infoblox
                                                               M. Cunche
                                                       INSA-Lyon & Inria
                                                              8 May 2026


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

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 9 November 2026                [Page 1]

Internet-Draft             IoT-DNS-Guidelines                   May 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 9 November 2026.

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 9 November 2026                [Page 2]

Internet-Draft             IoT-DNS-Guidelines                   May 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 9 November 2026                [Page 3]

Internet-Draft             IoT-DNS-Guidelines                   May 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 9 November 2026                [Page 4]

Internet-Draft             IoT-DNS-Guidelines                   May 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

   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.

   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.




Mishra, et al.           Expires 9 November 2026                [Page 5]

Internet-Draft             IoT-DNS-Guidelines                   May 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 9 November 2026                [Page 6]

Internet-Draft             IoT-DNS-Guidelines                   May 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 9 November 2026                [Page 7]

Internet-Draft             IoT-DNS-Guidelines                   May 2026


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

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












Mishra, et al.           Expires 9 November 2026                [Page 8]

Internet-Draft             IoT-DNS-Guidelines                   May 2026


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





Mishra, et al.           Expires 9 November 2026                [Page 9]

Internet-Draft             IoT-DNS-Guidelines                   May 2026


   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.

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

   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.

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 9 November 2026               [Page 10]

Internet-Draft             IoT-DNS-Guidelines                   May 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 9 November 2026               [Page 11]

Internet-Draft             IoT-DNS-Guidelines                   May 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 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.

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










Mishra, et al.           Expires 9 November 2026               [Page 12]

Internet-Draft             IoT-DNS-Guidelines                   May 2026


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

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







Mishra, et al.           Expires 9 November 2026               [Page 13]

Internet-Draft             IoT-DNS-Guidelines                   May 2026


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

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

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




Mishra, et al.           Expires 9 November 2026               [Page 14]

Internet-Draft             IoT-DNS-Guidelines                   May 2026


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

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



Mishra, et al.           Expires 9 November 2026               [Page 15]

Internet-Draft             IoT-DNS-Guidelines                   May 2026


   [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
   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 9 November 2026               [Page 16]
