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.