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

[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