Hi Éric, thank you for the review!
> On Oct 28, 2021, at 5:33 AM, Éric Vyncke via Datatracker <nore...@ietf.org> > wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks to Suzanne Woolf for the shepherd's write-up about the WG > consensus. > > Thank you also to Ron Bonica for the shortest (1 line) but positive review for > the Internet directorate: > https://secure-web.cisco.com/1jbJkhQyobZfJSmvsaMZeoGFdhMnstIYcTFajo1Q4Vr-CbsR5S5e8mFYoGc-Ne9ghqsEhgK0G36DyJQe-ZnMVNwjxMjwV2g6LrwwY3sO9ts9qb1jzShVafaFTeaFWakKikXfnicx4aEdtORvqF6TNyIcc8g4cNlNvptkD3jJ61pxlER2WobXcqR7pcPaFTKdUQ7vKOcrRa9jHgDA4i7G3dkRcQlA2JVoyMrj9Z9XtWB0ij4N4jL3a_wVh5-P4-gkJ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Freview-ietf-dnsop-dns-tcp-requirements-13-intdir-telechat-bonica-2021-10-26%2F > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > I would have expected a little more about anycast DNS servers as TCP is > probably a no-go for those servers. I see only one mention of anycast in the > whole document. RFC 7766 (which is the implementation requirements companion to this one) already says this about anycast: Long-lived TCP connections to anycast servers might be disrupted due to routing changes. Clients utilizing TCP for DNS need to always be prepared to re-establish connections or otherwise retry outstanding queries. It might also be possible for Multipath TCP [RFC6824] to allow a server to hand a connection over from the anycast address to a unicast address. IMO it doesn’t necessarily need to be repeated but there is probably no harm in doing so if there is consensus it is a good idea. > > -- Section 2.3 -- > To be honest, I smiled when reading "For example, as of 2014, DNS over TCP" in > 2021 ;-) > > -- Section 2.4 -- > The qualitative approach about IPv6 fragmentation makes me wonder about the > sources of this paragraph. > > Still about IPv6 fragmentation, while "hence is unable to fragment and re-send > anyway" is most probably correct, the originating host should populate its > Path > MTU cache for the destination. So, it is not that bad. This section has been rewritten based on feedback from others and your comment here. Does this look better now? For IPv6, the situation is a little more complicated. First, IPv6 headers are 40 bytes (versus 20 without options in IPv4). Second, approximately one third of DNS recursive resolvers use the minimum MTU of 1280 bytes [APNIC]. Third, fragmentation in IPv6 can only be done by the host originating the datagram. The need to fragment is conveyed in an ICMPv6 "packet too big" message. The originating host indicates a fragmented datagram with IPv6 extension headers. Unfortunately, it is quite common for both ICMPv6 and IPv6 extension headers to be blocked by middleboxes. According to [HUSTON] some 35% of IPv6-capable recursive resolvers were unable to receive a fragmented IPv6 packet. When the originating host receives a signal that fragmentation is required, it is expected to populate its Path MTU cache for that destination. The application, then, will retry the query after a timeout since the host does not generally retain copies of messages sent over UDP for potential retransmission. > > == NITS == > > -- Section 3 -- > While I appreciate 2nd degree, I wonder whether "serious" should really be > part > of "Furthermore, there has been serious research" Agreed. I’ve removed “serious” > > -- Section 4.4 -- > Should the DoT acronym be used ? My slight preference is to spell it out but I would defer to the working group and the RFC editor. DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
