That sounds good to me. However, you might want to rewrite the similar TCP paragraph, using 1388 instead of 1220.
Thanks. On Tue, Nov 11, 2025 at 4:21 AM Tobias Fiebig <[email protected]> wrote: > Moin, > > thanks, i see where the confusion (on my side) comes from: DNS Flagday > vs. 9715 vs. what implementations do (see appendix). > > I would suggest to reword this as follows then: > > In general, DNS servers SHOULD follow RFC9715 [RFC9715], which provides > additional guidance on preventing fragmentation by ensuring that the > maximum DNS/UDP payload size does not exceed 1400 octets. This can be > accomplished by setting a corresponding EDNS(0) size, with most > implementations using a lower EDNS(0) size of 1232 octets following > [DNSFlagDay2020], to ensure that generated packets always fit into > lower bound of the IPv6 MTU of 1280, as defined in [RFC8200]. > > With best regards, > Tobias > > On Mon, 2025-11-10 at 19:43 -0600, David Farmer wrote: > > The third paragraph of Section 3.2 of this draft does not accurately > > describe the recommendations in RFC9715; it does not recommend 1232 > > bytes, particularly R3, in Section 3.1 of RFC9715 recommends 1400 > > bytes. > > > > > In general, DNS servers SHOULD follow RFC9715 [RFC9715], which > > > provides additional guidance on preventing fragmentation by always > > > using a maximum EDNS(0) size of 1232 bytes. > > > > > RFC 9715, R3 says; > > > > > > UDP responders should compose response packets that fit in the > > > minimum of the offered requestor's maximum UDP payload size > > > [RFC6891], the interface MTU, the network MTU value configured by > > > the knowledge of the network operators, and the RECOMMENDED maximum > > > DNS/UDP payload size 1400. For more details, see Appendix A. > > > > > Thanks. > > > > On Mon, Nov 10, 2025 at 2:31 AM Tobias Fiebig > > <[email protected]> wrote: > > > Moin, > > > > > > (cross-post to v6ops@) > > > > > > as discussed in Montreal, Momoka and I just uploaded a new version > > > of > > > the document implementing several changes discussed on-site: > > > > > > - Simpler stub resolver selection w. a ref to RFC6724 (Lorenzo) > > > - Security considerations w. a ref to RFC9872 (Jen) > > > - Mention of libc limitations of 3 resolvers (Eric) > > > - Minor editorial changes > > > > > > With these changes, we believe this document to be ready. > > > > > > Also, as mentioned during DNSOP, we would appreciate it if the > > > chairs > > > could consider whether a WGLC might be feasible at this time. > > > > > > > > > With best regards, > > > Tobias > > > > > > On Mon, 2025-11-10 at 00:25 -0800, [email protected] wrote: > > > > A new version of Internet-Draft draft-ietf-dnsop-3901bis-06.txt > > > > has > > > > been > > > > successfully submitted by Momoka Yamamoto and posted to the > > > > IETF repository. > > > > > > > > Name: draft-ietf-dnsop-3901bis > > > > Revision: 06 > > > > Title: DNS IPv6 Transport Operational Guidelines > > > > Date: 2025-11-10 > > > > Group: dnsop > > > > Pages: 14 > > > > URL: > > > > https://www.ietf.org/archive/id/draft-ietf-dnsop-3901bis-06.txt > > > > Status: > > > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-3901bis/ > > > > HTML: > > > > https://www.ietf.org/archive/id/draft-ietf-dnsop-3901bis-06.html > > > > HTMLized: > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-3901bis > > > > Diff: > > > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-3901bis-06 > > > > > > > > Abstract: > > > > > > > > This memo provides guidelines and documents Best Current > > > > Practice > > > > for > > > > operating authoritative DNS servers as well as recursive and > > > > stub > > > > DNS > > > > resolvers, given that queries and responses are carried in a > > > > mixed > > > > environment of IPv4 and IPv6 networks. This document > > > > recommends > > > > that > > > > authoritative DNS servers as well as recursive DNS resolvers > > > > support > > > > both IPv4 and IPv6. It furthermore provides guidance for how > > > > recursive DNS resolvers should select upstream DNS servers, if > > > > synthesized and non-synthesized IPv6 addresses are available. > > > > > > > > This document obsoletes RFC 3901. (if approved) > > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > -- > Dr.-Ing. Tobias Fiebig > T +31 616 80 98 99 > M [email protected] > Pronouns: he/him/his > -- =============================================== David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
