Thanks very much. I will refer to your suggestions and try to shorten the introduction section.
-- Kazunori Fujiwara, JPRS <[email protected]> > From: Brian Dickson <[email protected]> > Fujiwara-san, > > I have a suggestion on tweaking the wording of Section 1, Introduction. > The intent is to simplify it a bit. Feel free to ignore this if it doesn't > work, > or use whatever parts of it you feel are useful. > > DNS has EDNS0 [RFC6891] mechanism. It enables a DNS server to send > large responses using UDP. EDNS0 is now widely deployed, and DNS > (over UDP) is said to be the biggest source of IP fragments. > > Fragmented DNS UDP responses have systemic weaknesses, which expose > the requestor to DNS cache poisoning from off-path attackers. (See appendix > for references and details.) The primary weakness is the UDP checksum itself, > and the fact that the UDP header and DNS header will be in the first fragment > only. > In addition, the IPv4 fragmentation and reassembly relies solely on the IPv4 > ID, > a 16-bit value which is weak enough to permit feasible brute force attacks. > > UDP has no inherent ability to react to ICMP messages that would otherwise > alert > the sender to dropped packets with DF=1, due to MTU being exceeded. > Additionally, fragmentation can adversely affect TCP performance, thus the > same logic > is applicable to both UDP and TCP. Fragmentation SHOULD be avoided. > > This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP > messages in order to avoid IP fragmentation, and describes how to > avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG. > > (Place the rest of the original introduction text and references into an > Appendix.) > > Feedback concerning this suggestion is welcome. > > Sincerely, > Brian Dickson _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
