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

Vernon Schryver <vjs@rhyolite.com> Mon, 13 February 2017 22:43 UTC

Return-Path: <vjs@rhyolite.com>
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 4F7A31299C2 for <dnsop@ietfa.amsl.com>; Mon, 13 Feb 2017 14:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Qe_vpbYzalFW for <dnsop@ietfa.amsl.com>; Mon, 13 Feb 2017 14:43:38 -0800 (PST)
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (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 261AA1299BD for <dnsop@ietf.org>; Mon, 13 Feb 2017 14:43:38 -0800 (PST)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v1DMhNUw062301 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org> env-from <vjs@rhyolite.com>; Mon, 13 Feb 2017 22:43:23 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v1DMhNKr062300 for dnsop@ietf.org; Mon, 13 Feb 2017 22:43:23 GMT
Date: Mon, 13 Feb 2017 22:43:23 +0000
From: Vernon Schryver <vjs@rhyolite.com>
Message-Id: <201702132243.v1DMhNKr062300@calcite.rhyolite.com>
To: dnsop@ietf.org
In-Reply-To: <1487024998.1521302.879922640.52B598B0@webmail.messagingengine.com>
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/O1UCx-x54QPFFn5yw1O3k3JT3Ug>
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 22:43:39 -0000

> 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.  No single legitimate recursive
server will make a lot of ANY requests per unit time.

An attack that might be intended involves many open recursive servers
(perhaps open only local infected eyeball stubs) being hit for only a
few requests each (or at least passing on only a few each request) for
your names but many all together.

However, in that case how many legitimate recursive servers will
send ANY requests to authorities?


Vernon Schryver    vjs@rhyolite.com