Some minor (editorial) issues I noticed in the current (19) draft:
3.1
R4. If the UDP responder detects an immediate error indicating that
the UDP packet cannot be sent beyond the path MTU size, the UDP
responder may recreate response packets fit in the path MTU size, or
with the TC bit set.
s/packets fit/packets that fit/ ? Or perhaps "to fit"?
I also find "the UDP packet cannot be sent beyond the path
MTU size" hard to interpret (specifically the "sending
beyond the path MTU size" part), do you mean "packet exceeds
the path MTU size"?
3.2. Proposed Recommendations for UDP requestors
R5. UDP requestors should limit the requestor's maximum UDP payload
size that fit in the minimum of the interface MTU, the network MTU
value configured by the knowledge of the network operators, and the
RECOMMENDED maximum DNS/UDP payload size 1400. A smaller limit may
be allowed. (See Appendix A for more information.)
s/that fit/to fit/ ?
s/by the knowledge of the network operators/by the network operators/ ?
Or perhaps "according to the knowledge of the network" (not operators)?
4. Proposed Recommendations for DNS operators
Large DNS responses are typically the result of zone configuration.
People who publish information in the DNS should seek configurations,
resulting in small responses.
The comma makes no sense here (should be dropped).
7.1. On-path fragmentation on IPv4
If the Don't Fragment (DF) bit is not set, on-path fragmentation may
happen on IPv4, and be vulnerable, as shown in Section 7.3. To avoid
this, recommendation R6 need to be used to discard the fragmented
responses and retry by TCP.
s/be vulnerable/lead to vulnerabilities/ ?
s/R6 need/R6 needs/ (or "should")
7.3. Weaknesses of IP fragmentation
[...]
"Domain Validation++ For MitM-Resilient PKI" [Brandt2018] proposed
that off-path attackers can intervene in the path MTU discovery
[RFC1191] to perform intentionally fragmented responses from
authoritative servers.
I didn't manage to obtain free access to the paper in the
limited time I was willing to spend on the matter, but the
way such papers are usually written is they describe attacks
and propose solutions, not the other way round (and the
abstract[1] seems to confirm that prejudice), so:
s/proposed/noted/ ?
And perhaps also rather "cause authoritative servers to
return/produce fragmented responses"?
[...]
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.
s/each of which/both/
7.5. Possible actions for resolver operators
[...]
Specifically, config the firewall functions before the full-service
resolver to discard incoming DNS response packets
s/config/configure/
s/before/in front of/ ? Or "protecting", to avoid any
spacial vs. temporal ambiguity?
Appendinx A.
[...]
in the interior of the
Internet between recursive resolvers and authoritative servers the
prevailing MTU is at 1,500
I realize this comes verbatim from the report text[2], but
for consistency/PoLA I suggest s/is at 1,500/is 1500/ (with
all the numbers and plus/minus/maximum/at least flying
around in the document I was at first wondering if "least"
might be missing after "at", and the comma is distracting at
best). Failing that, add quotation marks so that it is
clear that this is a quote from another document (following
different style).
Thank you,
Štěpán
[1] https://dl.acm.org/doi/10.1145/3243734.3243790#abstract
[2]
https://indico.dns-oarc.net/event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf
p. 27:
"Our measurements suggest that in the “interior” of the Internet between
recursive
resolvers and authoritative servers the prevailing MTU is at 1,500."
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
