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

John Kristoff <jtk@dataplane.org> Tue, 27 April 2021 14:58 UTC

Return-Path: <jtk@dataplane.org>
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 92BC73A0E59 for <dnsop@ietfa.amsl.com>; Tue, 27 Apr 2021 07:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 Z1_SQ5z9u_Xp for <dnsop@ietfa.amsl.com>; Tue, 27 Apr 2021 07:58:32 -0700 (PDT)
Received: from dataplane.org (dataplane.org [IPv6:2001:49f0:d0c4:3::2]) by ietfa.amsl.com (Postfix) with ESMTP id 79F8C3A0E53 for <dnsop@ietf.org>; Tue, 27 Apr 2021 07:58:32 -0700 (PDT)
Received: from p50.localdomain (localhost [127.0.0.1]) by dataplane.org (Postfix) with ESMTP id 8C841688001A; Tue, 27 Apr 2021 14:58:30 +0000 (UTC)
Date: Tue, 27 Apr 2021 09:58:30 -0500
From: John Kristoff <jtk@dataplane.org>
To: Tony Finch <dot@dotat.at>
Cc: "Wessels, Duane" <dwessels@verisign.com>, Suzanne Woolf <suzworldwide@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Message-ID: <20210427095830.43ad381a@p50.localdomain>
In-Reply-To: <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> <5c6c9d57-361c-ba79-6bb3-7936e188793@dotat.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ygR6UVjfab9ClE_xvkOkMFhdPfk>
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: Tue, 27 Apr 2021 14:58:38 -0000

On Thu, 22 Apr 2021 20:23:19 +0100
Tony Finch <dot@dotat.at> wrote:

> 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.

Hi Tony,

Minimal answers I think is an interesting and in a more general context
I'm interested in exploring it as an operational practice (e.g. I think
it can help relieve some of the burden and problems of parent/child
inconsistency).

However, I think we'd be reluctant to say much about minimal-answers
here in a context that suggests it is some sort of DDoS mitigation
mechanism and that you need it because... "TCP".  Maybe there is some
adjustments to the text somewhere that can help highlight that certain
RRsets or settings may lead to more TCP traffic?


Thanks for taking on a bulk of replies so far.  I tend to like to
digest them first, before replying to them in rapid succession so
you're beating me to it.  I can do some of the follow up work in the
repo where I find things that are not yet addressed.

> > > 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.)

IETF RFC 2136 (UPDATE) is already referenced in our draft, section
2.2.  Is this insufficient?

John