Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-11.txt

[Kazunori Fujiwara <[e-mail]>]

Mukund-san,

Thanks very much.

I updated my local version.
  http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html

--
Kazunori Fujiwara, JPRS <[e-mail]>

> From: Mukund Sivaraman <[e-mail]>
> Fujiwara-san, Vixie-san,
> 
> On Thu, Jan 19, 2023 at 12:13:02AM -0800, [e-mail] 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