iotops                                                         A. Mishra
Internet-Draft                                                     Inria
Intended status: Best Current Practice                          A. Losty
Expires: 28 August 2026                                  A. M. Mandalari
                                                                     UCL
                                                               J. Mozley
                                                                Infoblox
                                                               M. Cunche
                                                       INSA-Lyon & Inria
                                                        24 February 2026

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

Abstract

   This document outlines best current practices for Internet of Things
   (IoT) device providers regarding the implementation of DNS stub
   resolvers, with the aim of mitigating security threats, enhancing
   privacy, and resolving operational challenges.  It also provides
   guidelines for network operators on mitigating the risks identified
   in this draft as DNS resolution includes services outside of the
   stub-resolver, and for device providers' management zones.

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.

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

Mishra, et al.           Expires 28 August 2026                 [Page 1]
Internet-Draft             IoT-DNS-Guidelines              February 2026

   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 28 August 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.  Recommendations for IoT Device Stub Resolvers . . . . . . . .   4
     3.1.  Configuration of DNS servers used by IoT Stub
           Resolvers . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Source Port and Transaction ID Randomization  . . . . . .   5
     3.3.  Handling of TTL Values  . . . . . . . . . . . . . . . . .   5
     3.4.  Support of EDNS(0)  . . . . . . . . . . . . . . . . . . .   6
     3.5.  Improve Device Behavior in Response to Resolution
           Problems  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.6.  Compliance with Encrypted DNS Standards . . . . . . . . .   7
     3.7.  Use of DNSSEC . . . . . . . . . . . . . . . . . . . . . .   7
       3.7.1.  Stub-resolver Checking for Validation . . . . . . . .   9
       3.7.2.  Stub-resolver Performing Full Validation  . . . . . .   9
   4.  Recommendations for Network Operators . . . . . . . . . . . .  10
     4.1.  Resolvers Supporting DNSSEC . . . . . . . . . . . . . . .  10
     4.2.  Blocking of Unmanaged or Malicious DNS Traffic  . . . . .  10
     4.3.  Availability  . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Recommendations for Manufacturer Authoritative DNS Zones  . .  11
     5.1.  Zone Signing  . . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  TTL Values  . . . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12

Mishra, et al.           Expires 28 August 2026                 [Page 2]
Internet-Draft             IoT-DNS-Guidelines              February 2026

     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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.

   While the recommendations in this BCP may apply to all DNS stub
   resolver behavior, we treat IoT devices as a specific case where
   targeted recommendations are useful for the following reasons:

   *  The recommendations address specific IoT-related security concerns
      not seen in the DNS behavior of general-purpose operating systems

   *  IoT devices have different resource characteristics from general-
      purpose devices, such as constrained power consumption, meaning
      incorrect software implementations can have an increased
      operational impact

   *  IoT devices do not typically have security agents installed on
      them

   *  There are many DNS RFCs, and this BCP can be used to identify
      those related to specific security issues observed through
      research into IoT devices, with the aim of making it easier to
      address these vulnerabilities

   *  IoT devices may be deployed at scale on dedicated networks, and
      these recommendations will be useful to network security teams in
      mitigating vulnerabilities, especially where device behavior
      cannot be changed

   *  Manufacturers may use standard software distributions aimed at IoT
      devices without considering DNS behavior.  This BCP provides
      recommendations that can be used as part of the criteria to
      evaluate these distributions

   *  IoT devices typically perform the same set of DNS queries on
      start-up, which makes them both more vulnerable because of this
      predictable behavior and also more prone to fingerprinting

Mishra, et al.           Expires 28 August 2026                 [Page 3]
Internet-Draft             IoT-DNS-Guidelines              February 2026

   DNS terminology in this draft conforms to RFC 9499.  In this context,
   Stub Resolver refers to the IoT device, and Resolver refers to the
   DNS server used by the IoT device.

   The BCP is primarily concerned with device-to-cloud communication
   [RFC7452], but DNS may be used in other IoT device communication
   patterns.  Hence recommendations would apply to any deployment type
   where DNS is used, but decisions on implementation may be
   proportionate to security risks and operational considerations.  For
   example the implementation of {#configuring-resolvers} and
   Section 3.2 would be appropriate to any implementation, where as
   Section 3.6 may not be proportionate in industrial automation
   environments where devices do not encrypt other types of traffic
   [RFC9150].

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.  Recommendations for IoT Device Stub Resolvers

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

   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 discovered service should
   be selected.

   1.  Manual user configuration

   2.  Device management software

Mishra, et al.           Expires 28 August 2026                 [Page 4]
Internet-Draft             IoT-DNS-Guidelines              February 2026

   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.  This leaves them vulnerable to spoofed responses.  A
   combination of Source Port and Transaction ID is used, amongst other
   criteria, by the stub resolver when accepting a DNS response.

   IoT devices MUST undergo adequate Source Port and Transaction ID
   randomization in their DNS queries as a mitigation against cache
   poisoning from spoofed responses.  Having both of these values
   correctly randomized decreases the chances of a successful spoofed
   attack.  Stub resolvers MUST follow the recommendations of [RFC5452]
   as described in Section 4.5 to ensure Source Port randomization and
   Transaction ID randomization as required by [RFC1035].

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

Mishra, et al.           Expires 28 August 2026                 [Page 5]
Internet-Draft             IoT-DNS-Guidelines              February 2026

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

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 consuming
   additional processing resources and failing to maintain their network
   connectivity when responses to DNS requests exceed 512 bytes.

   IoT devices MUST support EDNS(0) and send a supported UDP packet size
   via OPT 41 [RFC6891].  To avoid fragmentation of UDP packets, which
   may be dropped by intervening networks, the maximum packet size
   SHOULD be set to 1220 bytes as a default, although device
   configuration MAY allow this to be configurable.  Although the
   networks to which IoT devices connect may support larger packet sizes
   than 1220 bytes, the nature of these devices in being deployed on
   many network types and DNS queries traversing networks controlled by
   different operators means it is operationally more effective to use
   this value.  In addition, IoT devices MUST support using TCP for
   queries when a TC bit is returned from the resolver [RFC1035].

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

Mishra, et al.           Expires 28 August 2026                 [Page 6]
Internet-Draft             IoT-DNS-Guidelines              February 2026

   The use of serve-stale [RFC8767] by resolver software on the IoT
   device may mitigate the impact of failed resolution, such as when
   authoritative servers are unavailable.  If the stub-resolver has this
   capability, device manufacturers should consider the benefits and any
   impact of using this.

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.

   IoT devices SHOULD support encrypted DNS protocols such as DNS over
   TLS (DoT) [RFC7858], DNS over QUIC (DoQ) [RFC9250], or DNS over HTTPS
   (DoH) [RFC8484] for enhanced privacy, security, and compatibility.
   To mitigate against fingerprinting IoT devices, DNS queries can be
   padded as detailed in [RFC7830] and [RFC8467].

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.  In addition, any validation of
   this type does not address the problem of man-in-the-middle (MiTM)
   attacks targeting DNS query responses.

   DNSSEC can be implemented by manufacturers to mitigate MitM attacks
   on DNS query responses.Manufacturers MUST sign public zones used for
   device management and services to ensure queries can be validated by
   their device stub-resolvers or more generally network resolvers that
   may use DNSSEC for validation.  This will improve security regardless
   of whether devices can support checking that queries are validated,
   as many network operators will implement validation by their
   resolvers.

   Manufacturers MAY improve device security by utilizing DNSSEC
   validation [RFC9364] on the stub-resolver.  Devices would typically
   adopt one of two models for validation (see Table 1) by setting a
   combination of the DO and CD bits in DNS queries:

Mishra, et al.           Expires 28 August 2026                 [Page 7]
Internet-Draft             IoT-DNS-Guidelines              February 2026

   *  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

   *  Stub-resolver performing 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.  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
   validation 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.

   Deployment options are summarised below, with two of them being the
   typical deployment cases:

   +=====+=====+============+===========+=============================+
   |  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

Mishra, et al.           Expires 28 August 2026                 [Page 8]
Internet-Draft             IoT-DNS-Guidelines              February 2026

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 so that it can utilize validation in
   a network that supports it, or falls 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 [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

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

Mishra, et al.           Expires 28 August 2026                 [Page 9]
Internet-Draft             IoT-DNS-Guidelines              February 2026

4.  Recommendations 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.
   Manufacturers should be aware of network operator DNS deployment
   options as devices will use these resolvers, even though this
   infrastructure is not under manufacturer control.

   As some aspects of DNS security rely on the stub-resolver, resolver,
   and authoritative server resolution process and 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.

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

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

4.3.  Availability

   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.

Mishra, et al.           Expires 28 August 2026                [Page 10]
Internet-Draft             IoT-DNS-Guidelines              February 2026

   Network operators SHOULD configure DNS resolvers to use serve-stale
   [RFC8767] 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.

   DNS queries are most commonly carried over UDP and compromised
   devices have been used in DoS attacks by sending queries with forged
   source addresses, hence network operators MUST implement [RFC2827]
   network ingress filtering.  Network operators should implement DNS
   Response Rate Limiting (RRL) on resolvers to mitigate high query
   volumes from devices causing DoS to the DNS infrastructure.

5.  Recommendations for Manufacturer Authoritative DNS Zones

5.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 4.1.  The zones used for these purposes
   SHOULD be publicly listed for network operators to use in securing
   their networks as described in Section 4.2.

5.2.  TTL Values

   As stated in Section 3.3 manufacturers MUST consider setting TTL
   values for management zone records that are appropriate for device
   operations, considering a balance between devices performing excess
   queries, continuous operation in the event of resolvers being
   unreachable, and the potential for changes in RDATA such as
   management IP addresses.

6.  Security Considerations

   This document does not include protocol changes so there are no
   specific security considerations in this draft related to new
   protocol implementations, rather the BCP focusses on security
   improvements by implementing existing protocols as in the sections
   above.

7.  IANA Considerations

   This document has no IANA actions.

8.  References

Mishra, et al.           Expires 28 August 2026                [Page 11]
Internet-Draft             IoT-DNS-Guidelines              February 2026

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

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

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

Mishra, et al.           Expires 28 August 2026                [Page 12]
Internet-Draft             IoT-DNS-Guidelines              February 2026

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

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

Mishra, et al.           Expires 28 August 2026                [Page 13]
Internet-Draft             IoT-DNS-Guidelines              February 2026

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

   [UCLandInriaPaper]
              "Towards Operational and Security Best Practices for DNS
              in the Internet of Things", n.d.,
              <https://hal.science/hal-05110445/>.

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

Mishra, et al.           Expires 28 August 2026                [Page 14]
Internet-Draft             IoT-DNS-Guidelines              February 2026

   Email: jmozley@infoblox.com

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

Mishra, et al.           Expires 28 August 2026                [Page 15]