Mukund-san, Thanks very much.
I updated my local version. http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > From: Mukund Sivaraman <m...@mukund.org> > Fujiwara-san, Vixie-san, > > On Thu, Jan 19, 2023 at 12:13:02AM -0800, internet-dra...@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations WG of the >> IETF. >> >> Title : Fragmentation Avoidance in DNS >> Authors : Kazunori Fujiwara >> Paul Vixie >> Filename : draft-ietf-dnsop-avoid-fragmentation-11.txt >> Pages : 10 >> Date : 2023-01-19 >> >> Abstract: >> EDNS0 enables a DNS server to send large responses using UDP and is >> widely deployed. Large DNS/UDP responses are fragmented, and IP >> fragmentation has exposed weaknesses in application protocols. It is >> possible to avoid IP fragmentation in DNS by limiting response size >> where possible, and signaling the need to upgrade from UDP to TCP >> transport where necessary. This document proposes techniques to >> avoid IP fragmentation in DNS. > > Is there still time to mention some editorial nits? If so, please see > the following; I am sorry I did not review the recent revision earlier. > > >> 1. Introduction > >> DNS has an EDNS0 [RFC6891] mechanism. It enables a DNS server to >> send large responses using UDP. EDNS0 is now widely deployed, and >> DNS (over UDP) relies on on IP fragmentation when the EDNS buffer > > I suggest removing the brackets around "(over UDP)", and fix the typo of > two "on"s: > > i.e, write it as "... and DNS over UDP relies on IP fragmentation..." > >> This document proposes that implementations set the "Don't Fragment >> (DF) bit" [RFC0791] on IPv4 and not using the "Fragment header" > > "... and not use the \"Fragment header\"..." > >> [RFC8200] on IPv6 in DNS/UDP messages in order to avoid IP >> fragmentation, and describes how to avoid packet losses due to DF bit > > "... fragmentation. It also describes..." > >> 2. Terminology > >> "Requestor" refers to the side that sends a request. "Responder" >> refers to an authoritative, recursive resolver or other DNS component > > "... to an authoritative server, recursive resolver or..." > >> 3. Proposal to avoid IP fragmentation in DNS > >> These recommendations are intended for nodes with global IP addresses >> on the Internet. Private networks or local networks are out of the >> scope of this document. > >> The methods to avoid IP fragmentation in DNS are described below: > >> 3.1. Recommendations for UDP responders > >> * UDP responders SHOULD send DNS responses without "Fragment header" >> [RFC8200] on IPv6. > >> * UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF) >> bit" [RFC0791] on IPv4. > > I suggest using the RFC 2119 term SHOULD here as well (synonymous with > RECOMMENDED), so that when reading the text, the recommendation doesn't > appear of a different severity from the other items. > > "UDP responders SHOULD set the IP \"Don't Fragment flag (DF)..." > >> * UDP responders SHOULD compose response packets that fit in both > > "both" implies 2, whereas there are 3 things suggested. I suggest > deleting the word "both" and keeping the rest of the text. > >> the offered requestor's maximum UDP payload size [RFC6891], the >> interface MTU, and the RECOMMENDED maximum DNS/UDP payload size >> 1400. > >> * If the UDP responder detects an immediate error that the UDP > > "... immediate error indicating that the..." > >> packet cannot be sent beyond the path MTU size (EMSGSIZE), the UDP >> responder MAY recreate response packets fit in path MTU size, or >> TC bit set. > > "... recreate response packets to fit in the path MTU size, or with the > TC bit set." > >> * UDP responders SHOULD limit response size when UDP responders are > > "... SHOULD limit the response size..." > >> located on small MTU (<1500) networks. > >> 3.2. Recommendations for UDP requestors > >> * UDP requestors SHOULD limit the requestor's maximum UDP payload >> size to the RECOMMENDED size of 1400 or smaller size. > > "... or a smaller size." > >> * UDP requestors MAY drop fragmented DNS/UDP responses without IP >> reassembly to avoid cache poisoning attacks. > >> * DNS responses may be dropped by IP fragmentation. Upon a timeout, >> to avoid name resolution fails, UDP requestors MAY retry using TCP > > "... to avoid resolution failures, ..." > >> or UDP with a smaller requestor's maximum UDP payload size per > > "... smaller EDNS requestor's maximum UDP payload size..." > >> local policy. > > >> 4. Recommendations for zone operators and DNS server operators > >> Large DNS responses are the result of zone configuration. Zone >> operators SHOULD seek configurations resulting in small responses. >> For example, > >> * Use a smaller number of name servers (13 may be too large) > > Haha :) > >> * Use a smaller number of A/AAAA RRs for a domain name > >> * Use 'minimal-responses' configuration: Some implementations have a >> 'minimal responses' configuration that causes DNS servers to make > > "Use minimal responses configuration: Some implementations have a > "minimal-responses" configuration option that..." > >> response packets smaller, containing only mandatory and required >> data (Appendix C). > >> * Use a smaller signature / public key size algorithm for DNSSEC. >> Notably, the signature sizes of ECDSA and EdDSA are smaller than >> those for RSA. > > "... those usually used for RSA." > >> 7. Security Considerations > >> If a UDP respone packet is dropped (for any reason), it increases the > > s/respone/response/ > >> attack window for poisoning the requestor's cache. > > >> Appendix A. Weaknesses of IP fragmentation > >> A DNS message receiver cannot trust fragmented UDP datagrams >> primarily 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. By comparison, TCP protocol stack controls >> packet size and avoid IP fragmentation under ICMP NEEDFRAG attacks. > > s/avoid/avoids/ > >> In TCP, fragmentation should be avoided for performance reasons, >> whereas for UDP, fragmentation should be avoided for resiliency and >> authenticity reasons. > >> Appendix B. Details of requestor's maximum UDP payload size discussions > >> There are many discussions for default path MTU size and requestor's >> maximum UDP payload size. > >> * The minimum MTU for an IPv6 interface is 1280 octets (see >> Section 5 of [RFC8200]). Then, we can use it as the default path > > s/Then,/So,/ > >> MTU value for IPv6. The corresponding minimum MTU for an IPv4 >> interface is 68 (60 + 8) [RFC0791]. > > >> * In order to avoid IP fragmentation, [DNSFlagDay2020] proposed that >> the UDP requestors set the requestor's payload size to 1232, and >> the UDP responders compose UDP responses fit in 1232 octets. The > > "... compose UDP responses so they fit in 1232 octets." > >> size 1232 is based on an MTU of 1280, which is required by the >> IPv6 specification [RFC8200], minus 48 octets for the IPv6 and UDP >> headers. > >> * [Huston2021] analyzed the result of [DNSFlagDay2020] and reported >> that their measurements suggest that in the interior of the >> Internet between recursive resolvers and authoritative servers the >> prevailing MTU is at 1,500 and there is no measurable signal of >> use of smaller MTUs in this part of the Internet, and proposed >> that their measurements suggest setting the EDNS0 Buffer size to > > Here, does "EDNS Buffer size" mean the EDNS requestor's UDP payload size > (RFC 6891 section 6.2.3) or EDNS UDP response datagram's size? > >> IPv4 1472 octets and IPv6 1452 octets. > > " .. 1472 octets for IPv4, and 1562 octets for IPv6. > > >> Appendix C. Minimal-responses > >> Some implementations have a 'minimal responses' configuration that > > "... have a \"minimal-responses\" configuration setting/option..." > >> causes a DNS server to make response packets smaller, containing only >> mandatory and required data. > >> Under the minimal-responses configuration, A DNS server composes the > > s/A/a/ > >> response message using only the RRSet corresponding to the query. In > > This is not exactly correct (consider a CNAME response). It's better to > write it as: > > "... a DNS server composes responses containing only necessary RRs." > >> the case of delegation, see [I-D.ietf-dnsop-glue-is-not-optional]. > > s/In the case of delegation, see.../For delegations, see .../ > >> In case of a non-existent domain name or non-existent type, the >> authority section will contain an SOA record and the answer section >> is empty. (defined in Section 2.1 and 2.2 of [RFC2308]). > > "... is empty (defined in..." (remove period after empty) > > Mukund _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
