[DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-avoid-fragmentation-16: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# GEN AD review of draft-ietf-dnsop-avoid-fragmentation-16

CC @larseggert

Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/VBI2ri6JwD9TEPjcxKBi828dVs4).

## Comments

### Paragraph 2
```
                     IP Fragmentation Avoidance in DNS
```
Title should clarify this is for DNS over UDP.

### Section 1, paragraph 5
```
     This document specifies various techniques to avoid IP fragmentation
     of UDP packets in DNS.
```
Really wish that this BCP made a much stronger recommendation for DNS over TCP.

### Section 3.1, paragraph 0
```
  3.1.  Recommendations for UDP responders
```
I find myself agreeing with other ballots on these recommendations.
Will refrain from duplicating them (and also from holding another DISCUSS
based on them.)

### Section 3.1, paragraph 3
```
     At the time of writing, most DNS server software did not set the DF
     bit for IPv4, and many OS kernel constraints make it difficult to set
     the DF bit in all cases.  Best Current Practice documents should not
     specify what is currently impossible, so R2, which is setting the DF
     bit, is "MAY" rather than "SHOULD".
```
Maybe I'm familiar with different kernels, but all the ones I am
familiar with (except for some IoT platforms) readily offer socket
options to set DF (and prevent stack fragmentation in v6).

### Section 3.1, paragraph 3
```
     R3.  UDP responders SHOULD compose response packets that fit in the
     minimum of the offered requestor's maximum UDP payload size
     [RFC6891], the interface MTU, and the RECOMMENDED maximum DNS/UDP
     payload size 1400.
```
Why SHOULD, i.e., when would it ever be OK to do this? Also, where
does the 1400 byte value come from (magic constant?)

### Section 3.1, paragraph 3
```
     R5.  UDP responders SHOULD limit the response size when UDP
     responders are located on small MTU (<1500) networks.
```
Limit *to what*?

### Section 4, paragraph 0
```
  4.  Recommendations for zone operators and DNS server operators
```
I find it somewhat questionable to recommend changes in how DNS is
being operated just to cater to UDP needing to remain a viable
transport. (I realize I may be an outlier here.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Document references `draft-ietf-dnsop-svcb-https`, but that has been published
as `RFC9460`.

### Grammar/style

#### "Appendix B.", paragraph 3
```
fter two UDP timeouts, BIND 9 will fallback to TCP. C.2. Knot DNS and Knot R
                                   ^^^^^^^^
```
The word "fallback" is a noun. The verb is spelled with a space.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool