Index: draft-ietf-dnsop-avoid-fragmentation.mkd =================================================================== RCS file: /home/fujiwara/.cvsroot/ietfid/draft-ietf-dnsop-avoid-fragmentation.mkd,v retrieving revision 1.50 retrieving revision 1.52 diff -u -b -r1.50 -r1.52 --- draft-ietf-dnsop-avoid-fragmentation.mkd 8 Dec 2022 07:25:40 -0000 1.50 +++ draft-ietf-dnsop-avoid-fragmentation.mkd 21 Dec 2022 09:54:14 -0000 1.52 @@ -1,7 +1,7 @@ --- title: Fragmentation Avoidance in DNS abbrev: avoid-fragmentation -docname: draft-ietf-dnsop-avoid-fragmentation-09 +docname: draft-ietf-dnsop-avoid-fragmentation-10 stand_alone: true @@ -155,7 +155,7 @@ Introduction ===== -DNS has EDNS0 [RFC6891] mechanism. +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) is said to be the biggest user of IP fragmentation. @@ -178,7 +178,7 @@ lacks insight into IP header and option size, and so must make more conservative estimates about available UDP payload space. -This document proposes to set "Don't Fragment flag (DF) bit" [RFC0791] on IPv4 +This document proposes to set the "Don't Fragment flag (DF) bit" [RFC0791] on IPv4 and not to use "Fragment header" [RFC8200] on IPv6 in DNS/UDP messages in order to avoid IP fragmentation, and describes how to @@ -201,7 +201,7 @@ between a source node and a destination node. (Quoted from [RFC8201]) In this document, the term "Path MTU discovery" includes -both Classical Path MTU discovery [RFC1191], [RFC8201] and +both Classical Path MTU discovery [RFC1191], [RFC8201], and Packetization Layer Path MTU discovery [RFC8899]. Many of the specialized terms used in this document are defined in @@ -212,7 +212,7 @@ These recommendations are intended for nodes with global IP addresses on the Internet. -Private networks or local networks are out of scope of this document. +Private networks or local networks are out of the scope of this document. The methods to avoid IP fragmentation in DNS are described below: @@ -230,7 +230,7 @@ to measure path MTU discovery attacks, interface MTU and the requestor's maximum UDP payload size [RFC6891]. -- If the UDP responder detects immediate error +- If the UDP responder detects an immediate error that the UDP 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. @@ -238,16 +238,16 @@ - UDP responders SHOULD limit response size when UDP responders are located on small MTU (<1500) networks. - The cause and effect of the TC bit is unchanged from EDNS0 [RFC6891]. + The cause and effect of the TC bit are unchanged from EDNS0 [RFC6891]. Recommendations for UDP requestors ----------------------------------- -- UDP requestors SHOULD limit the requestor's maximum UDP payload size as 1400 or smaller size. +- UDP requestors SHOULD limit the requestor's maximum UDP payload size to 1400 or smaller size. \[ UDP requestors MAY set the requestor's maximum UDP payload size as 1232. \] - UDP requestors MAY perform "Path MTU discovery" - per destination to use requestor's maximum UDP payload size + per destination to use the requestor's maximum UDP payload size larger than 1400. Then, calculate their requestors' maximum UDP payload size as the reported path MTU minus IPv4/IPv6 header size (20/40) minus UDP header size (8). @@ -259,7 +259,7 @@ Upon a timeout, to avoid name resolution fails, UDP requestors MAY retry using TCP - or UDP with smaller requestor's maximum UDP payload size + or UDP with a smaller requestor's maximum UDP payload size per local policy. Request to zone operators and DNS server operators @@ -269,16 +269,16 @@ Zone operators SHOULD seek configurations resulting in small responses. For example, -- Use smaller number of name servers (13 may be too large) +- Use a smaller number of name servers (13 may be too large) -- Use smaller number of A/AAAA RRs for a domain name +- Use a smaller number of A/AAAA RRs for a domain name - Use 'minimal-responses' configuration: - Some implementations have 'minimal responses' configuration that causes + Some implementations have a 'minimal responses' configuration that causes DNS servers to make response packets smaller, containing only mandatory and required data ({{minimal-responses}}). -- Use smaller signature / public key size algorithm for DNSSEC. +- Use a smaller signature / public key size algorithm for DNSSEC. Notably, the signature size of ECDSA or EdDSA is smaller than RSA. Considerations @@ -289,9 +289,9 @@ In prior research ([Fujiwara2018] and dns-operations mailing list discussions), there are some authoritative servers -that ignore EDNS0 requestor's maximum UDP payload size, and return large UDP responses. +that ignore the EDNS0 requestor's maximum UDP payload size, and return large UDP responses. -It is also well known that there are some authoritative servers that do not +It is also well known that some authoritative servers do not support TCP transport. Such non-compliant behavior cannot become implementation or configuration @@ -313,7 +313,7 @@ and which may lead to TCP fallback. This would indicate prior reliance upon IP fragmentation, which is universally considered to be harmful -to both performance and stability of applications, endpoints, and gateways. +to both the performance and stability of applications, endpoints, and gateways. Avoiding IP fragmentation will improve operating conditions overall, and the performance of DNS/TCP has increased and will continue to increase. @@ -381,7 +381,7 @@ - The minimum MTU for an IPv6 interface is 1280 octets (see Section 5 of [RFC8200]). - Then, we can use it as default path MTU value for IPv6. + Then, we can use it as the default path MTU value for IPv6. The corresponding minimum MTU for an IPv4 interface is 68 (60 + 8) [RFC0791]. @@ -390,7 +390,7 @@ Maximum DNS/UDP payload size for IPv6 on MTU 1500 ethernet is 1452 (1500 minus 40 (IPv6 header size) minus 8 (UDP header size)). To allow for possible IP options and distant tunnel overhead, - authors' recommendation of default maximum DNS/UDP payload size is 1400. + the authors' recommendation of default maximum DNS/UDP payload size is 1400. - [RFC4035] defines that "A security-aware name server MUST support the EDNS0 message size extension, MUST support a message @@ -405,7 +405,7 @@ by the IPv6 specification [RFC8200], minus 48 octets for the IPv6 and UDP headers. -- [Huston2021] analyzed the result of [DNSFlagDay2020], reported that +- [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 @@ -417,21 +417,21 @@ Minimal-responses {#minimal-responses} ====== -Some implementations have 'minimal responses' configuration that causes +Some implementations have a 'minimal responses' configuration that causes a DNS server to make response packets smaller, containing only mandatory and required data. Under the minimal-responses configuration, DNS servers compose response messages using only RRSets corresponding to queries. -In case of delegation, DNS servers compose response packets with -delegation NS RRSet in authority section +In the case of delegation, DNS servers compose response packets with +delegation NS RRSet in the authority section and in-domain (in-zone and below-zone) glue in the additional data section. -In case of non-existent domain name or non-existent type, +In case of a non-existent domain name or non-existent type, the start of authority (SOA RR) will be placed in the Authority Section. In addition, if the zone is DNSSEC signed and a query has the DNSSEC OK bit, -signatures are added in answer section, -or the corresponding DS RRSet and signatures are added in authority section. +signatures are added in the answer section, +or the corresponding DS RRSet and signatures are added in the authority section. Details are defined in [RFC4035] and [RFC5155].