Some minor (editorial) issues I noticed in the current (19) draft: 3.1
R4. If the UDP responder detects an immediate error indicating that the UDP packet cannot be sent beyond the path MTU size, the UDP responder may recreate response packets fit in the path MTU size, or with the TC bit set. s/packets fit/packets that fit/ ? Or perhaps "to fit"? I also find "the UDP packet cannot be sent beyond the path MTU size" hard to interpret (specifically the "sending beyond the path MTU size" part), do you mean "packet exceeds the path MTU size"? 3.2. Proposed Recommendations for UDP requestors R5. UDP requestors should limit the requestor's maximum UDP payload size that fit in the minimum of the interface MTU, the network MTU value configured by the knowledge of the network operators, and the RECOMMENDED maximum DNS/UDP payload size 1400. A smaller limit may be allowed. (See Appendix A for more information.) s/that fit/to fit/ ? s/by the knowledge of the network operators/by the network operators/ ? Or perhaps "according to the knowledge of the network" (not operators)? 4. Proposed Recommendations for DNS operators Large DNS responses are typically the result of zone configuration. People who publish information in the DNS should seek configurations, resulting in small responses. The comma makes no sense here (should be dropped). 7.1. On-path fragmentation on IPv4 If the Don't Fragment (DF) bit is not set, on-path fragmentation may happen on IPv4, and be vulnerable, as shown in Section 7.3. To avoid this, recommendation R6 need to be used to discard the fragmented responses and retry by TCP. s/be vulnerable/lead to vulnerabilities/ ? s/R6 need/R6 needs/ (or "should") 7.3. Weaknesses of IP fragmentation [...] "Domain Validation++ For MitM-Resilient PKI" [Brandt2018] proposed that off-path attackers can intervene in the path MTU discovery [RFC1191] to perform intentionally fragmented responses from authoritative servers. I didn't manage to obtain free access to the paper in the limited time I was willing to spend on the matter, but the way such papers are usually written is they describe attacks and propose solutions, not the other way round (and the abstract[1] seems to confirm that prejudice), so: s/proposed/noted/ ? And perhaps also rather "cause authoritative servers to return/produce fragmented responses"? [...] due to the small amount of entropy provided by UDP port numbers and DNS message identifiers, each of which being only 16 bits in size, and both likely being in the first fragment of a packet if fragmentation occurs. s/each of which/both/ 7.5. Possible actions for resolver operators [...] Specifically, config the firewall functions before the full-service resolver to discard incoming DNS response packets s/config/configure/ s/before/in front of/ ? Or "protecting", to avoid any spacial vs. temporal ambiguity? Appendinx A. [...] in the interior of the Internet between recursive resolvers and authoritative servers the prevailing MTU is at 1,500 I realize this comes verbatim from the report text[2], but for consistency/PoLA I suggest s/is at 1,500/is 1500/ (with all the numbers and plus/minus/maximum/at least flying around in the document I was at first wondering if "least" might be missing after "at", and the comma is distracting at best). Failing that, add quotation marks so that it is clear that this is a quote from another document (following different style). Thank you, Štěpán [1] https://dl.acm.org/doi/10.1145/3243734.3243790#abstract [2] https://indico.dns-oarc.net/event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf p. 27: "Our measurements suggest that in the “interior” of the Internet between recursive resolvers and authoritative servers the prevailing MTU is at 1,500." _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
