Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

Tony Finch <dot@dotat.at> Mon, 13 February 2017 23:29 UTC

Return-Path: <dot@dotat.at>
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 B3D1D1299F7 for <dnsop@ietfa.amsl.com>; Mon, 13 Feb 2017 15:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.com
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 GQaDLza_Vpd2 for <dnsop@ietfa.amsl.com>; Mon, 13 Feb 2017 15:29:51 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4022B129A00 for <dnsop@ietf.org>; Mon, 13 Feb 2017 15:29:42 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8E1FA20992; Mon, 13 Feb 2017 18:29:41 -0500 (EST)
Received: from web1 ([10.202.2.211]) by compute4.internal (MEProxy); Mon, 13 Feb 2017 18:29:41 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=N6 4bL9g1lbZzoBeyqRG9L6gPWRQ=; b=OvMAuTDZ0+GznRqcGvO+mVSqJFQzmrfk7O oAPUTGRuhY+UCLQf0ibhUDTJZY1TZETcSxSmaPuuqlSBZW6bOtgEp1bjdt2Og3L0 Y90Omx458QwGnSvR/1/0fXqWKh3IgQp4y8fnj8U2W8seOq271xkzHZ1sHAylTbgm yJQk9yq7E=
X-ME-Sender: <xms:ZUGiWEEuxgm4OkQfyHCYOd9ER4EXkXXKd_MWk02IreZUbqht13WP4g>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6EB4EAA6C8; Mon, 13 Feb 2017 18:29:41 -0500 (EST)
Message-Id: <1487028581.1533622.879980992.48B3C400@webmail.messagingengine.com>
From: Tony Finch <dot@dotat.at>
To: Vernon Schryver <vjs@rhyolite.com>, dnsop@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_148702858115336220"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-3dff962b
References: <201702132243.v1DMhNKr062300@calcite.rhyolite.com>
In-Reply-To: <201702132243.v1DMhNKr062300@calcite.rhyolite.com>
Date: Mon, 13 Feb 2017 23:29:41 +0000
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XVUX2GXiprTtMIDSwLacZLWLV6M>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Feb 2017 23:29:53 -0000


Vernon Schryver <vjs@rhyolite.com> wrote:

> > From: Tony Finch <dot@dotat.at>

>

> > One of the points of minimal-any is that the answer is not truncated
> > because you do not want clients to automatically retry over TCP.
> > This is
> > to handle situations where many third-party recursive servers
> > are under
> > attack using one of your names, so the recursive servers are hitting
> > your authoritative servers hard. RRL does not work in this case,
> > because
> > the clients are legitimate recursive servers. You want to give
> > them an
> > answer asap, that they can cache without hitting TCP.

>

> On the contrary, as that case is described, RRL works fine, and

> this minimal-any mechanism won't help the obvious attack situation

> in that might be intended.

>

> Each legitimate recursive server will ask once per some TTL and

> cache the rrsets that it gets. 



Not if the authoritative server is overloaded and has run out of TCP
sockets and is unable to answer the question. The recursive servers will
all then be perpetually retrying while the attack continues, so the
authoritative servers will never recover from overload.


> However, in that case how many legitimate recursive servers will

> send ANY requests to authorities?



In the case of this attack it was thousands.



Tony.

--

f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--
  zr8h punycode