Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

Tony Finch <dot@dotat.at> Mon, 19 April 2021 15:45 UTC

Return-Path: <fanf2@hermes.cam.ac.uk>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9593A36F5 for <dnsop@ietfa.amsl.com>; Mon, 19 Apr 2021 08:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.071
X-Spam-Level:
X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro5TK3DnA1fy for <dnsop@ietfa.amsl.com>; Mon, 19 Apr 2021 08:45:26 -0700 (PDT)
Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565A93A36E7 for <dnsop@ietf.org>; Mon, 19 Apr 2021 08:45:25 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from [84.9.76.236] (port=53008 helo=milebook.lan) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpsa (PLAIN:fanf2) (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1lYW5T-000Q5V-6l (Exim 4.94) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 19 Apr 2021 16:45:23 +0100
Date: Mon, 19 Apr 2021 16:45:22 +0100
From: Tony Finch <dot@dotat.at>
To: Suzanne Woolf <suzworldwide@gmail.com>
cc: dnsop@ietf.org
In-Reply-To: <93D82731-7B33-4E39-8DEF-FF6C14803191@gmail.com>
Message-ID: <da3dceaf-26d7-dddd-6c31-21fd35227f91@dotat.at>
References: <93D82731-7B33-4E39-8DEF-FF6C14803191@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OGx-R7VQ4TDMfXgxg6Xu3WtqW40>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2021 15:45:31 -0000

Suzanne Woolf <suzworldwide@gmail.com> wrote:
>
> This message starts the Working Group Last Call for
> draft-ietf-dnsop-tcp-requirements

I have read the draft and I am keen to see it published. Just the other
day I was having a discussion about whether TCP support is really needed,
and I wanted something stronger than RFC 7766 to point to.

The draft is readable and comprehensive. I like it.

Some minor and pedantic nits:

2.2:

   DNSSEC originally specified in [RFC2541]

I thought this should be RFC 2535 rather than the operational guidelines?

2.3:

   This unsigned 16-bit field specifies, in bytes, the maximum
   (possibly fragmented) DNS message size a node is capable of
   receiving.

I suggest adding "over UDP" to the end of the sentence (since the EDNS
buffer size doesn't restrict messages over other transports).

2.4:

Last 2 paragraph s re. avoiding fragmentation, it might be worth
suggesting minimal-any [RFC 8482].

4.3:

   the Linux kernel provides a number of "sysctl" parameters related to
   TIME_WAIT, such as net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_recycle,
   and net.ipv4.tcp_tw_reuse.

I believe that net.ipv4.tcp_tw_recycle is problematic and has been removed
https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux#netipv4tcp_tw_recycle

4.4:

   Although DNS-over-TLS utilizes TCP port
   853 instead of port 53, this document applies equally well to DNS-
   over-TLS.

Um, how much of this document applies to DoT? Just the tuning advice, or
the requirement that TLS MUST be supported like TCP MUST be?

5:

re "DDoS mitigation techniques" would it be worth citing DNS RRL here as
well as in section 9?

10:

   Since DNS over both UDP and TCP use the same underlying message
   format, the use of one transport instead of the other does change the
   privacy characteristics of the message content

Missing "not"?

A:

Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm
not sure how much UDP is used, but I certainly rely on 60+ KB updates.

Also RFC 8482 section 4.4 talks about possible different behaviour for ANY
queries over UDP compared to TCP.

A.8:

   [RFC3226] strongly argued in favor of UDP messages over TCP largely

I had to read this twice! How about "instead of" instead of "over"?

A.14:

I think there should be a note that RFC 5966 has been obsoleted by RFC
7766, with a cross-reference to A.21.


(that's all I spotted)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  https://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and
North Channel: Southeasterly 3 to 5 at first in west, otherwise
southwesterly 2 to 4, becoming variable 3 or less. Smooth or slight,
occasionally moderate near Mull of Kintyre. Occasional rain. Good,
occasionally moderate.