Skip to main content

IP Fragmentation Avoidance in DNS over UDP
draft-ietf-dnsop-avoid-fragmentation-17

Yes

Warren Kumari

No Objection

Jim Guichard
Mahesh Jethanandani

No Record

Deb Cooley
Francesca Palombini
Gunter Van de Velde
Orie Steele
Zaheduzzaman Sarker

Summary: Needs one more YES or NO OBJECTION position to pass.

Paul Wouters
Yes
Comment (2023-12-29 for -16) Sent
        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".

If what you want is "we really really want this but it cannot be done on every OS",
then I think SHOULD instead of MUST is fine, but MAY seems too weak.

        R7. UDP requestors MAY drop fragmented DNS/UDP responses without
        IP reassembly to avoid cache poisoning attacks.

        R8. DNS responses may be dropped by IP fragmentation. Upon a
        timeout, to avoid resolution failures, UDP requestors MAY retry
        using TCP or UDP with a smaller EDNS requestor's maximum UDP
        payload size per local policy.

Same here. R7 and R8 are "recommendations" so I feel the MAY's should be SHOULDs.
Otherwise the recommendation becomes "do whatever you MAY please", in which case
why are these in the document?


        R9. Use a smaller number of name servers (13 may be too large)

I would say "name server names" instead of "name servers", to avoid any ambiguity
of anycast name servers operating under the same name. Eg the document is not
saying "use less than 13 name servers", but it is saying "use less than 13 name
server names"


        smaller than those usually used for RSA.

smaller than those of equivalent cryptographic strength using RSA
Warren Kumari
Yes
Erik Kline
No Objection
Comment (2024-01-02 for -16) Sent
# Internet AD comments for draft-ietf-dnsop-avoid-fragmentation-16
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S1

* "TCP avoids fragmentation by ..."

  TCP also benefits hugely from widespread support for MSS rewriting.  If
  something like an "EDNS0 Payload Size rewriting" function was available
  and as widely deployed there might be a very different conversation to
  be had.

  No text changes necessary; just a random thought.
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2024-01-03 for -16) Not sent
I support Rob's DISCUSS position.
Mahesh Jethanandani
No Objection
Murray Kucherawy
(was Discuss) No Objection
Comment (2024-03-17) Sent
Thanks for addressing my DISCUSS and Barry's remaining ARTART review point.

I support Rob Wilton's DISCUSS position.  Piling on a bit, in reference to:

   R6.  UDP requestors SHOULD limit the requestor's maximum UDP payload
   size to the RECOMMENDED size of 1400 or a smaller size.

I think the "RECOMMENDED" here is just carrying forward a "RECOMMENDED" from someplace else.  If that's correct, I suggest changing it to "recommended" or, if you want to be more precise, "... to the size recommended by RFCXXXX of 1400 or smaller."  Now it's clear what the SHOULD is referencing, and you don't own the RECOMMENDED part here.

I suggest defining "EMSGSIZE" in Section 2 to be the UNIX error code of the same name.  Otherwise, we encounter it in Section 3.1 in a way that could mean it's an error code (which is how I think you intend it) or as a symbolic name for the path MTU size.

Forwarded comments from Orie Steele, incoming ART Area Director:

"Recommendations for zone operators and DNS server operators"

* Define "large / small" better.

"Protocol compliance considerations"

* Would be nice to see reporting recommendations, perhaps that make the failure an internal cost for the failing component?... would not want a repeat of dmarc though.
Roman Danyliw
No Objection
Comment (2024-01-03 for -16) Sent
Thank you to Donald Eastlake for his SECDIR review.  Please review his proposed text on including clarifying language around the applicability of TSIG.

I support Martin Duke and Rob Wilton’s DISCUSS positions.

** Section 7.2
   This would indicate prior
   reliance upon IP fragmentation, which is universally considered to be
   harmful to both the performance and stability of applications,
   endpoints, and gateways.

Is there a reference that can be cited to substantiate this “universal” position?
Éric Vyncke
No Objection
Comment (2024-01-04 for -16) Sent
Thank you for this document, DNS is so important for the global Internet that a BCP is welcome. I am afraid that for several reasons I was unable to review correctly this document on time, mainly relying on Vladimír Čunát's DNS-dir review at https://datatracker.ietf.org/doc/review-ietf-dnsop-avoid-fragmentation-16-dnsdir-telechat-cunat-2023-12-27/ .

Nevertheless, I support Rob's DISCUSS about the use of MAY/SHOULD about the IPv4 DF-bit in section 3.1; also, an assertion like `many OS kernel constraints make it difficult to set the DF bit` should be backed by a reference.

I also find 'light' to rely on TCP MSS as it is set by the end points only, i.e., it can also leads to IPv4 fragmentation in the path (or IPv6 fragmentation by the kernel at the source).

Section 3, does `These recommendations are intended for nodes with global IP addresses on the Internet` also cover the use of NAT/NPT when the requestor uses RFC 1918 addresses or ULA?

In section 3.1:

- R1 why not simply stating that there should be no IPv6 fragmentation ? Atomic fragments are now discouraged for IPv6

- R3 where is the packet size of 1400 coming from ? Some reasoning would be welcome (e.g., based on some measurements over the global Internet). Put at least a forward reference to the appendix.

In section 4, R9: where is `13 may be too large` coming from ?

Appendix `the authors' recommendation` is it a recommendation by the authors or by the IETF in an IETF stream document?

-éric
Deb Cooley
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Orie Steele
No Record
Zaheduzzaman Sarker
No Record
Lars Eggert Former IESG member
No Objection
No Objection (2024-01-04 for -16) Sent
# 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
Martin Duke Former IESG member
(was Discuss) No Objection
No Objection (2024-03-04) Sent
Thanks for addressing my DISCUSS.

Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for responding.

(1) I support Rob's DISCUSS (and Paul's comment) about SHOULD/MAY. "do it unless the OS makes it impossible" is a typical use of SHOULD.

(2) Section 3.1, R1 says that responders SHOULD omit the fragment header. Under what circumstances would it be reasonable to keep it?
Robert Wilton Former IESG member
(was Discuss) No Objection
No Objection (2024-03-13) Sent
Thanks for addressing my comments.

Regards,
Rob