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

"Wessels, Duane" <> Fri, 05 November 2021 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85D943A102B; Fri, 5 Nov 2021 14:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VqdtpEYtOx18; Fri, 5 Nov 2021 14:49:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DE243A0EDE; Fri, 5 Nov 2021 14:49:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; l=5608; q=dns/txt; s=VRSN; t=1636148949; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=UY74aXAVKS0d3s/2M4g802xHIzH7FTZbrOpVd6cU4Z0=; b=TtnctGECl8Ss6N3x4SjMYUWK/Js/wOZZDBvGgSx+Scz+8INo5kvQB/bW 3MHXbkmQXAjimzhQQQQROFdcza/WP0JLSinhVO525YtHLcINy3aaMIl0X vC7i3FXfBhEQIRzdiaFrb+CEx5UL5XqPEKS4vJZMfiCCjGuGdJuFAYkrw cT2R2sc168ZEN3XcGPaeLSUrlvMS35Hc1hIlI9shyk0Q4PzdxL58Trmw3 mfCx6mN/nG9EBHTmETecStq9P6TjERIERUBe3Ha0YXqjovKu74OjU7ZWT jRw7ny+3v/ggGqMAGX3PNrYtqY2Wx0k6exdCdhXIvOsCuFTqw0LkrQRbp w==;
IronPort-SDR: oke0XxLQf21QUsAg/D8EFExvnLwt1aN1AvnPqAxK6VPg3KSuFqbm19BL4N6ZHC49wt7om1MlN/ Z8tAsg4oF641p4I02p/QhlwDaVLm7C87W5H2O0ZkloYBLxlFx0Qk52Fo8QNfGqRLareXIzO+9U zqL4otbbbIuYW0Ympx+cgSE7UTuA6+NwJ/hbUDQBtRGVtv3smlCP0y4tZDr+qmO2WQaAOHd61x qYuuPRd6W0PWg0Jvz3Tms6l4+Ej/ecV2IeTkOeO+QnDj3sC0TqSg+Cuz3WBWds+qluokFVHupd JqA=
IronPort-Data: A9a23:O30Ie6q5K9fcq5EhVVa07DaqVgleBmICZBIvgKrLsJaIsI4StFCzt garIBmCOP3ZYmWkL41/bIjg9E4DsJeBm4QxTlA9+Ss9QSMS9ZacVYWSI3mrMnLJJKUvbq7HA +byyzXkBJppJpMJjk71atANlZT/vE2xbuKU5NTsY0idfic5Dnd+4f5fs7Rh2Ncx2IDkW1jlV e7a+KUzBnf0g1aYDUpJs8pvmDs31BglkGpF1rCWTakjUG72zxH5PrpGTU2CByKQrr1vIwKPb 72rIIdVXo/u10xF5tuNyt4Xe2VUGuKCZVDmZnB+A8BOiTAazsA+PzpS2FPxpi67hh3Q9+2dx umhurSPeRcnOq7VpN8jaAh1DQ1wZvNDw5L+dC3XXcy7lyUqclPG+dM3M2cbDdVBvPh8BntWs /UUbi4XdRbFjOWzqF65YrA0wJ18d4+yYdhZ5iEIITLxVJ7KRbjPXKjR/tJcxx8ui9pPBvfRY YwSbj8HgBHoOkUQaw1NUMxWcOGA3WDmfCNA71CumPA8w3XJ9yIq75P/L4+AEjCNbYAP9qqCn UrL4XX/CRIXHNee0jGCtHmrg4fnnC7gV6oTGaG2sPlwjzW7ynYaBgFTVFanr7y1jFW5Q5dTL VdR5iE26LI/7VGqVNT4Uhuku1aFswISHd1KHIUS5AeWzbKR6AaQB3IfZj9MdNJgs9U5LRQm0 ESOh/voCCBh9rqPRhq17aqGsjSoPSQKLGMPTSABRAoBpdLkpekOYgnnRMxlSbGzg82tQHTr3 SrMqSklwr8Uy8QR0fz940rchXSnoZ2hohMJ2zg7l1mNtmtRDLNJraTxgbQHxZ6s9Lqkc2Q=
IronPort-HdrOrdr: A9a23:6zdEUqyk4zoL9Trh3gv/KrPw/L1zdoMgy1knxilNoERuA6ilf8 DHppgmPYedskdtZJhSo6HmBEDmewKhyXcV2/hqAV7MZmnbUQeTRr2KqLGSpgEIeBeOidK1t5 0QEJSWYeeYZTNHZITBkWuF+r0br+VvhZrIuQ6o9RlQpG9RBp2IpD0JbDpzWncGPTWvlfICZe KhD+R81kGdRUg=
X-IronPort-AV: E=Sophos;i="5.87,212,1631592000"; d="scan'208";a="10792206"
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 5 Nov 2021 17:49:05 -0400
Received: from ([fe80::a89b:32d6:b967:337d]) by ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2308.015; Fri, 5 Nov 2021 17:49:05 -0400
From: "Wessels, Duane" <>
To: Éric Vyncke <>
CC: The IESG <>, "" <>, "" <>, "" <>, Suzanne Woolf <>
Thread-Topic: [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
Thread-Index: AQHX0o70KFXqjxKmzUutLqzA9rdchw==
Date: Fri, 05 Nov 2021 21:49:05 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3608.
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Nov 2021 21:49:13 -0000

Hi Éric, thank you for the review!

> On Oct 28, 2021, at 5:33 AM, Éric Vyncke via Datatracker <> wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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:
> 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.