I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with Issues. Security -------- In Section 7.3, the second paragraph on DNSSEC does not seem to belong in a section on "Weaknesses of IP fragmentation". I suggest moving it to a new Section 7.4 entitled "DNS Security Protections" or the like. Not only should the existing DNSSEC material be moved there but there should be some mention of transaction authentication. The existing document completely ignores RFC 8945 and RFC 2931 transaction authentication which, it seems to me, when used, overcome the security infirmities of fragmented UDP. Furthermore, transaction security protects delegation responses. Perhaps adding something like "DNS transaction security [RFC8945] [RFC2931] does protect against the security risks of fragmentation including protecting delegation responses. But [RFC8945] has limited applicability due to key distribution requirements and there is little if any deployment of [RFC2931]." There seem to be inconsistent implementation requirements for recommendation R7. R7 itself says "MAY" but Section 7.1 says "should" in such a way that I think it should be capitalized "SHOULD". Also, I think the last sentence of 7.1 should be deleted and recommendation R2 made a "SHOULD". Minor ----- This draft has scattered statements in it that seem in need of qualification or rewording to be correct. Abstract: "Large DNS/UDP responses are fragmented" -> "Larger DNS/UDP messages are more likely to be fragmented" Couldn't a request have lots of Additional Information RRs and be large? Section 1. Introduction:, last sentence of first paragraph: It isn't the DNS buffer size that causes fragmentation, it's caused by big packets. There may be applications where all the packets are not that large. There are lots of ways to fix this sentence, of which perhaps the simplest would be to add "In the general case" to the beginning of the sentence. Other possibilities are things like "DNS over UDP relies on IP fragmentation when a packet is larger than the path MTU, which is invited by an EDNS buffer size larger than the path MTU." Section 1. Introduction, first sentence of 3rd paragraph top of page 3: summarized -> states Section 1. Introduction, last paragraph, page 3: First sentence is fine. I don't understand just what the rest of the paragraph is saying or why it is useful. A "path MTU" can be "obtained" (not set?) through "static configuration, server routing hints, ..."? Is this configuration/hint affecting transit devices so as to limit/expand the path MTU? What's going on here? Section 3., first paragraph: So, down here we learn that private/local networks are out of scope. This limitation should be earlier, like in the Abstract and Introduction. I also suggest considering flipping it around and saying "This document is primarily applicable to DNS use on the global Internet." R2: While a BCP certainly shouldn't say "MUST" for something that is "currently impossible", I don't see why it can't say "SHOULD" to push things in the right direction. "MAY" is pretty wimpy. R5 seems redundant with part of R3. The last sentence in Section 3.1, which is after R5, seems more applicable to R4 and should probably be moved up to between R4 and R5. Also, that sentence uses RFC 6891 as the reference for "the TC bit". But the TC bit has only one minor occurrence in RFC 6891. I believe RFC 1035 is the appropriate reference. Section 7.2 says "... fragmentation, which is universally considered to be harmful ..." I don't like "universally" as it might overpower the scope limitation to exclude private/local networks in some readers' minds and it is my understanding that within an over provisioned local network, fragmentation can be quite reliable and improve performance. How about "... fragmentation, which is considered harmful on the global Internet"? Appendix C: I think you should make up your mind and either tell the RFC Editor to remove this before publication or to retain it. I would definitely lean towards removal. Nits ---- R1: 'without "Fragment' -> 'without a "Fragment' R2: "OS" is used only once here in the explanation after the recommendation. Just spell it out. R4: "in path MTU size" -> "in the path MTU size" Section 4: The first two recommendations do not end with a period although all other recommendations do end with a period. Section 5: I would add something right after the Section 5 header like "Some authoritative servers deviate from the DNS standard as follows:" and then make the current first two sentences in Section 5 indented and/or numbered or otherwise clearly a list. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com