Thanks, pushed an -07 for this. With best regards, Tobias
On Tue, 2025-11-11 at 16:08 -0600, David Farmer wrote: > 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 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
