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 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
