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

Tony Finch <dot@dotat.at> Thu, 22 April 2021 19:23 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 0F4883A0D39 for <dnsop@ietfa.amsl.com>; Thu, 22 Apr 2021 12:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level:
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fCV0FwiQsS3Z for <dnsop@ietfa.amsl.com>; Thu, 22 Apr 2021 12:23:53 -0700 (PDT)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 4844A3A0DD5 for <dnsop@ietf.org>; Thu, 22 Apr 2021 12:23:27 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from [90.251.236.55] (port=65113 helo=milebook.lan) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpsa (PLAIN:fanf2) (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1lZev6-000AEg-0B (Exim 4.94) (return-path <fanf2@hermes.cam.ac.uk>); Thu, 22 Apr 2021 20:23:24 +0100
Date: Thu, 22 Apr 2021 20:23:19 +0100
From: Tony Finch <dot@dotat.at>
To: "Wessels, Duane" <dwessels@verisign.com>
cc: Suzanne Woolf <suzworldwide@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>
In-Reply-To: <7591E59C-5E52-44C6-8AEE-346393969367@verisign.com>
Message-ID: <5c6c9d57-361c-ba79-6bb3-7936e188793@dotat.at>
References: <93D82731-7B33-4E39-8DEF-FF6C14803191@gmail.com> <da3dceaf-26d7-dddd-6c31-21fd35227f91@dotat.at> <7591E59C-5E52-44C6-8AEE-346393969367@verisign.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/pNfbURkw4GX3itugVNPWG2AO_pE>
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: Thu, 22 Apr 2021 19:23:58 -0000

Wessels, Duane <dwessels@verisign.com> wrote:
>

Thanks for looking through my suggestions! All the changes look good.
A few follow-up points:

> Oops, correcting myself here.  It needs to be RFC 2541 because that is the
> one that mentions TCP.

Aha, that makes sense

> > 2.4:
> >
> > Last 2 paragraph s re. avoiding fragmentation, it might be worth
> > suggesting minimal-any [RFC 8482].
>
> I did add 8482 to the Appendix as you also suggested below.  I'm a
> little reluctant to add a reference in section 2.4 since I think the
> primary motivation for 8482 was about DDoS amplification, rather than
> fragmentation.  But I could still be convinced otherwise.

I needed minimal-any when my auth servers were being hammered by lots of
recursive servers making ANY requests; the responses were being truncated
because my servers have for a long time been configured to avoid
fragmentation, and the retries over TCP caused an overload.

I tend to think of all settings that reduce response size as tools for
avoiding fragmentation. Which makes me realise that BIND's
minimal-responses setting is probably also worth a mention. (I dunno if
other servers have a similar knob?)

> > 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.
>
> I probably don't have enough direct experience with UPDATE to say.  If
> it is largely over TCP then I think it should be included.

I listed the main section numbers that mention TCP. One point in RFC 2136
that's notable from an operational point of view is that an UPDATE client
has to use TCP if it wants to be sure to get a response. Unlike QUERY,
UPDATE is not idempotent so UPDATE-over-UDP can't be retried when there is
packet loss. (But `nsupdate` still uses UDP for small changes; I run it
over localhost which is reliable enough.)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  https://dotat.at/
East Forties: Northwesterly 3 to 5. Moderate. Showers. Good.