Skip to main content

Early Review of draft-ietf-iotops-iot-dns-guidelines-04
review-ietf-iotops-iot-dns-guidelines-04-secdir-early-farrell-2026-07-29-00

Request Review of draft-ietf-iotops-iot-dns-guidelines
Requested revision No specific revision (document currently at 04)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2026-07-31
Requested 2026-07-09
Requested by Alexey Melnikov
Authors Abhishek Kumar Mishra , Andrew Losty , Anna Maria Mandalari , Jim Mozley , Mathieu Cunche
I-D last updated 2026-07-24 (Latest revision 2026-07-06)
Completed reviews Dnsdir Early review of -01 by Patrick Mevzek (diff)
Secdir Early review of -04 by Stephen Farrell
Iotdir Early review of -04 by Lou Berger
Assignment Reviewer Stephen Farrell
State Completed
Request Early review on draft-ietf-iotops-iot-dns-guidelines by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/ZvlwkS-gfB0enkwabfpsPZIPA-Q
Reviewed revision 04
Result Has issues
Completed 2026-07-29
review-ietf-iotops-iot-dns-guidelines-04-secdir-early-farrell-2026-07-29-00
I marked this as "has issues" just because it's an early review and
everything at that stage has issues:-) I'd say "on the right track"
would be more accurate.

general:

- this has a lot of MUST statements that together seem over-optimistic, is
  that the right target? I wonder how many device vendors or n/w operators
  have reviewed this? (If "not many" then getting such review would seem
  like a good plan.)

- The last para of 3.7.2 seems to amount to: do s/w updates - why not say
  it that way? And make that a high level recommendation?

- I see no mention of mDNS, mightn't that be used for finding services?

specific:

- abstract: what's a management zone?

- 3.1: is the "MUST NOT fall back" to public recursives really practical or
  likely to be honoured?

- 3.1: how likely is it that DDR will be implemented?

- 3.1: the bullet list: any guidance on how often to run that recursive
  selection alg? on reboot? every day?

- 3.2: did you consider randomising the capitalization of the QNAMEs? (I
  forget if that's currently considered good or bad:-)

- 3.3: "manufs MUST configure" sounds like RFC6919 "but we know you won't"

- 3.6: Most forms of encrypted DNS implies some root store - that's maybe
  new for IoT devices, so how's it expected to work? If the answer is to
  mosly do that depending on the OS root store, that'd be ok but maybe 
  worth a mention.

- 3.6: Why not SHOULD be padded?

- 3.7: "Note that manufacturers MUST have signed public zones used for
  device management and services so that validation can take place" - that
  seems like a bogus MUST. s/MUST/need to have/ would seem more accurate.
  (Same in 4.1)

- 3.7.1: "falls back to unvalidated queries" seems wrong, aren't those
  unvalidated answers? 

- 3.7.2: wouldn't the additional DNS traffic be an issue for some devices?

- 3.7.2: the DNSSEC trust anchor is easy enough, compared to the root
  store for DoT/DoH. Seems odd to mention the easy one and not the
  hard one.

- 5.2: MUD could do with a reference.