Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

["Wessels, Duane" <[e-mail]>]

Hi Éric, thank you for the review!



> On Oct 28, 2021, at 5:33 AM, Éric Vyncke via Datatracker <[e-mail]> 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