[Iotops] Revised draft-ietf-iotops-iot-dns-guidelines-01

[Jim Mozley <[e-mail]>]

Hi iotops,

I’ve uploaded a new version of this draft reflecting feedback from the list and comments during IETF124. Feedback welcome as we can then consider it and adjust the draft again well before 125 so we can update the WG at that meeting.


Changes are summarised below:

- Added informative reference for UCL and Inria summary paper that’s publicly available (iotops list comment)
- Changed sections such as “Compliance with Encrypted DNS Standards” to have more rationale in the first paragraph to make the “why is this necessary?” clearer
- Fixed some formatting and referencing mistakes
- Changed around wording in section “Configuration of DNS servers used by IoT Stub Resolvers”
- Moved content from “Security Considerations” section to dedicated sections for network operators and manufacturers authoritative DNS zones, as per the discussion in the IETF 124 iotops WG (Eliot Lear comment)
- Changed the order of the stub-resolver BCPs to what seemed more logical e.g. acquiring IP addresses first
- Move network operator advice in “Improve Device Behavior in Response to Resolution Problems” into the new Network Operator section
- Reviewed which references should be considered normative and which are informative, where a MUST is stated the reference has been made normative
- Added into the intro that the BCP is primarily concerned with device-to-cloud communication {{?RFC7452}} but could be used in any communication pattern, and noted that some of the BCP recommendations may be implemented proportionally (Hannes Tschofenig comment)


Other notes:

- We’ll need more discussion on which classes of devices this applies to (I’d assume all that use DNS) as per “I would also expect a reference to draft-ietf-iotops-7228bis (https://datatracker.ietf.org/doc/draft-ietf-iotops-7228bis/) and a clear statement about which classes of IoT devices the recommendations are intended for.”. (Hannes Tschofenig comment)
- In the end omitted ECH “Another missing topic is the encrypted ClientHello (ECH). If DNS traffic is encrypted but the FQDN later appears in the unencrypted TLS ClientHello, the privacy benefits are limited. This should be acknowledged and discussed.” with the reasoning that mandating ECH is outside of the scope of DNS security issues. (Hannes Tschofenig comment)
- Not altered the need for DNSSEC. Continued IoT botnet activity such as https://securelist.com/evasive-panda-apt/118576/ could have been mitigated by DNSSEC “For typical DNS usage, I am not convinced that DNSSEC adds much value when TLS is used afterwards—an attacker who can spoof DNS messages cannot make much progress in such a scenario. Some text on this point would help clarify the position of the draft. If you would, however, store keys in the DNS (as it is done with DANE/DANCE) then the story is different. You are, however, silent on DANE/DANCE.”. Is DANE used in any IoT deployments?”. (Hannes Tschofenig comment)
- Document left as a BCP “Finally, I am not convinced that BCP is the appropriate category for this document. It seems difficult to argue “Best Current Practice” when encrypted DNS is virtually unheard of in constrained IoT environments. I also wonder whether the document should focus solely on privacy, rather than mixing privacy and security considerations.” This BCP is focussed more on security than privacy findings and comes out of research into home IoT devices. We could state this in the draft BUT if any device is using DNS it should follow fundamental protocol standards such as using DNS source port and transaction ID randomisation. (Hannes Tschofenig comment)


Questions for the working group

- We state “Devices SHOULD use the following priority order for selecting a resolver. The first one that results in a discovered service should be selected.” In section 3.1, but is this appropriate for dual-stack environments?
- Having moved more general advice from the Security Considerations section (as advised during the IETF 124 WG meeting) there is some duplication, so we’ve used internal references to avoid as much of this as possible. We think that having this slight duplication under a specific section such as “Recommendations for Manufacturer Authoritative DNS Zones” will help in implementing the BCP as there are then recommendations under the three core elements of resolution i.e. stub-resolver > resolver > authoritative server
- An alternative structure would be to have the draft recommendation focussed e.g. remove stub-resolver, resolver and authoritative zones and have a section on DNSSEC
- A previous comment was to stick closely to the BCP for just the devices themselves (stub-resolver), but given the nature of DNS resolution and the mitigation that can be made outside the device it seems appropriate to include these where they are in the context of observed device security related issues. Nothing has been added in this context with the move to stub-resolver, network operator and manufacturer authoritative sections, it is more of a document organisational change that hopefully is better from an implementation point of view
- Is RFC2827 network ingress filtering too far outside the scope of the BCP?




Begin forwarded message:

From: [e-mail]
Subject: [Iotops] I-D Action: draft-ietf-iotops-iot-dns-guidelines-01.txt
Date: 23 January 2026 at 13:17:54 GMT
To: <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]

!-------------------------------------------------------------------|
 This Message Is From an External Sender
 This message came from outside your organization.
|-------------------------------------------------------------------!

Internet-Draft draft-ietf-iotops-iot-dns-guidelines-01.txt is now available.
It is a work item of the IOT Operations (IOTOPS) WG of the IETF.

  Title:   IoT DNS Security and Privacy Guidelines
  Authors: Abhishek Mishra
           Andrew Losty
           Anna Maria Mandalari
           Jim Mozley
           Mathieu Cunche
  Name:    draft-ietf-iotops-iot-dns-guidelines-01.txt
  Pages:   14
  Dates:   2026-01-23

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.

The IETF datatracker status page for this Internet-Draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-iotops-iot-dns-guidelines/__;!!JYsgTRAg6ZQ!PVMCG9HohCRGbzb0sAYIKgcDWBpsy3FNV4XejaJpl2Tog5X3FCjeS62eyqI66azU55ja2vzLNP3zFkF0kiBcZvUZo2fe$

There is also an HTMLized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-iotops-iot-dns-guidelines-01__;!!JYsgTRAg6ZQ!PVMCG9HohCRGbzb0sAYIKgcDWBpsy3FNV4XejaJpl2Tog5X3FCjeS62eyqI66azU55ja2vzLNP3zFkF0kiBcZmdBRCAh$

A diff from the previous version is available at:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-iotops-iot-dns-guidelines-01__;!!JYsgTRAg6ZQ!PVMCG9HohCRGbzb0sAYIKgcDWBpsy3FNV4XejaJpl2Tog5X3FCjeS62eyqI66azU55ja2vzLNP3zFkF0kiBcZjf6rYsS$

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


--
Iotops mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]