(just reformatting of bottom parts to be more readable, sorry) Hi, I have been selected as the DNS Directorate reviewer for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir I don't think the draft is ready as it stands, while not being maybe very far from it. I didn't check on the specific working group mailing list if there were already discussions on the draft. I didn't read the research paper, either. Sorry in advance if I am repeating points already raised. Here are my comments in a loosely decreasing order of importance (from “showstoppers” to “I don't understand fully/Could be clearer” and then “nitpicks”): — Generic comment: the title says “guidelines” but then the document uses “BCP” a lot of times; I don't think IETF BCPs are written by referencing themselves as BCP, since this “status” comes only at publication time (and if for some reason the BCP status is not achieved, then the document reads all strange); I don't know the IETF process close enough, but maybe there is a need to specifically request to be published as a BCP, if that is the goal. Also, the first mention of BCP (in “While the recommendations in this BCP”) outside IETF boilerplate is not expanded to be explained. — Generic comment: related to above, I am confused by various paragraphs that mention RFCs but don't actually give “guidelines” at all, saying things like “device manufacturers should consider the benefits and any impact of using this.” (for example, for the “serve stale” part). This is very vague and high level, so looks more like “List of stuff to look around” than actionable examples (like possible positive or negative impacts to study) and guidelines. — I find it a bit strange to have “Security” right in the title of the document, but basically an empty Security Considerations section. I don't think only protocol changes have security impact. If nothing else, there should be at least a short paragraph summarizing again why the application of above guidelines given will increase security (and possibly clearly explaining impacts on security of device, impacts on security of network around the device, and impacts on the DNS zones and resolution process used by the IoT devices using these guidelines). — “the maximum packet size SHOULD be set to 1220 bytes as a default”. Why 1220? 2020 DNS Flag Day (https://www.dnsflagday.net/2020/) recommended everyone to switch to 1232. But otherwise maybe reference RFC 9715 which deals with fragmentation and recommends 1400, and by doing so you avoid having to chose and hardcode any value yourself. — subjective and maybe just me, but by reading the abstract and then all the document, it was never 100% clear to me if the goal was to define security for the IoT device itself, for the, supposedly manufacturer of said IoT device controlled network security, or for security at large of any Internet resource based on that device behavior. It seems to me each part is touched by the document somehow. Also, as for structure, since all these RFCs cited are everywhere in the document, maybe consider have a list of them in a specific section summarizing quickly how they relate to IoT devices and a one sentence summary of what to get from them in this context? — “stub resolver” is introduced very early, but not explained. Probably reference RFC 9499 on DNS Terminology, and specifically §6. I see RFC 9499 mentioned later (“DNS terminology in this draft conforms to RFC 9499.” but strangely that RFC is not listed in references?) and then stub resolver explained, but I believe the order should be swapped so that you define stub resolver even before going into the bullet points of §1. Also, I don't think Stub Resolver and Server needs uppercases (or else, they should be there for all occurrences). Some global uniformity could be goal too as later we have “Configuration of DNS servers” but immediately after “DNS resolvers” so I think it would be better to choose once for all “DNS server” or “DNS resolver” and use it accordingly everywhere (otherwise it might always bring the questioning if those are 2 different things or not?) — “The first one that results in a discovered service should be selected.” Seems a big vague for me. What does “discovered service” exactly mean? Getting at least one working reply? What does “first one” also exactly means, considering multiple servers can be defined for each case? — “IoT devices do not typically have security agents installed on them”: what are “security agents”? No examples given (which would make it easier to understand why IoT devices don't have them contrary to generic computers, I guess?). Agents securing against what? Same remark later in §4 about “security software agents”. — in §3.2 I am not sure of the usefulness and clarity of the end with “to ensure Source Port randomization and Transaction ID randomization as required by [RFC1035].”, specifically since RFC1035 doesn't talk at all about randomization — in §3.3 “In case of unsuccessful resolution, such as when the resolver is unavailable, IoT devices should implement exponential back-off strategies.” could be improved I think, because “unsuccessful resolution” could be either no reply or negative reply, and in later case the negative TTL should apply. RFC9520 details all cases of “unsuccessful” and maybe could be referenced here? (§3.2 of it mention backoff). — in §3.5 not sure why serve stale is mentioned here because it is obviously about serving data, so it applies to a plain resolver, not a stub one. This is again mentioned, and then correctly placed I think, in §4.3 — in §3.6, not sure about “for enhanced privacy, security, and compatibility.” after mentioning DoT/DoQ/DoH… privacy of? The IoT device? Compatibility about what and between what? — “In addition, IoT devices MUST support using TCP for queries when a TC bit is returned from the resolver [RFC1035].” this seems to me to imply that TCP is only for those cases, where the initiator should be free to use UDP or TCP at anytime (and has to use TCP for case of TC=1), so relax things to allow TCP for any case? — §3.7.2 “Devices will need to be shipped with a root trust anchor and have a mechanism to securely update this”. No mention of RFC5011 for automated updates of root anchors? — in §3.7.2 last sentence seems basically to tell “do 3.7.1 instead”, and if so, that advice seems to me better in 3.7 before detailing the options. — in §4.2: “Manufacturer Usage Descriptions (MUDs)” is mentioned without explanations of what it is or reference about it, yet the capitalization and acronym makes it look like as something widespread/well-known/obvious. — Not sure, but shouldn't at least the following “should” be IETF “SHOULD” instead: * “IoT devices should implement exponential back-off strategies.” * “Devices should cache results including intermediate validation results to reduce repeated computation” * “As described in Section 3.7 resolvers should be configured to validate DNS responses using DNSSEC.” * “Network operators should implement DNS Response Rate Limiting (RRL) on resolvers to mitigate high query volumes from devices causing DoS to the DNS infrastructure.” — nit: “mitigating the risks identified in this draft” s/draft/document/ or similar — nit: “may apply to all DNS stub resolver behavior” no plural? — nit: “The BCP is primarily concerned” s/The/This/ ? — “For example the implementation of {#configuring-resolvers} and Section 3.2”: missing/wrong reference for the {} part? — maybe better phrasing: “For example the implementation […] would be appropriate to any implementation,” to reduce duplication of implementation? — nit: “When Encrypted resolver options” the RFC referenced, RFC9463 has either “encrypted resolver” (no uppercase) or “Encrypted DNS Option” (all uppercase), I recommend picking either of the terms from the RFC — nit (consistency): “If the stub-resolver has this capability” please choose between “stub resolver” (13 occurrences) and “stub-resolver” (10 occurrences) across the whole document — nit (layout): broken bullet points after “IoT stub-resolvers may adopt one of two models for validation:” — nit: §3.7.2 “Device stub-resolvers can perform validation themselves” why the plural?