Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

Mark Andrews <marka@isc.org> Fri, 05 February 2016 22:42 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560711B2E58 for <dnsop@ietfa.amsl.com>; Fri, 5 Feb 2016 14:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.302
X-Spam-Level:
X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 9FnqWjPjxEWs for <dnsop@ietfa.amsl.com>; Fri, 5 Feb 2016 14:42:20 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68ABF1B2E51 for <dnsop@ietf.org>; Fri, 5 Feb 2016 14:42:20 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id A0F493493BE; Fri, 5 Feb 2016 22:42:17 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E4D9316009E; Fri, 5 Feb 2016 22:42:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D83F416009D; Fri, 5 Feb 2016 22:42:51 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id f4ZVOfJ1HsNp; Fri, 5 Feb 2016 22:42:51 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 9BE6B160035; Fri, 5 Feb 2016 22:42:51 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E32A1419B60F; Sat, 6 Feb 2016 09:42:14 +1100 (EST)
To: Tony Finch <dot@dotat.at>
From: Mark Andrews <marka@isc.org>
References: <alpine.LSU.2.00.1602052158390.7000@hermes-2.csi.cam.ac.uk>
In-reply-to: Your message of "Fri, 05 Feb 2016 22:10:08 -0000." <alpine.LSU.2.00.1602052158390.7000@hermes-2.csi.cam.ac.uk>
Date: Sat, 06 Feb 2016 09:42:14 +1100
Message-Id: <20160205224214.E32A1419B60F@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/FeX_HjbXrgWZGdVhQTnlR-r0-oA>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 05 Feb 2016 22:42:22 -0000

In message <alpine.LSU.2.00.1602052158390.7000@hermes-2.csi.cam.ac.uk>, Tony Fi
nch writes:
> Last weekend one of our authoritative name servers
> (authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
> rather unhappy. Over the last week I have developed a patch for BIND to
> implement draft-ietf-dnsop-refuse-any which should allow us to handle
> ANY flood attacks better. http://fanf.livejournal.com/140566.html
> 
> I still have a potential problem with RRSIG queries, which work a lot like
> ANY queries. Cloudflare's approach is to simply refuse them, which makes a
> lot of sense because RRSIG queries don't have the same interop concerns as
> ANY queries. However, in an attack like the ones we had last weekend where
> the queries arrived at our authoritative servers from lots of real
> recursive servers, a refusal will cause retries and make the attack worse.
> 
> Would it be reasonable as an alternative to follow the refuse-any approach
> and just return the RRSIG(s) for one RRset? If so, I think this suggestion
> should be included in the draft.
 
Yes, for both SIG and RRSIG.  They are not useful queries on their
own.  I am discounting the corner case of a non DNSSEC aware recursive
server in front of a validating client as that does not work reliably
with DNS loose coherency.

Mark

> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Thames, Dover: Southwest 5 to 7, occasionally gale 8 later, perhaps severe
> gale 9 later. Moderate, occasionally rough later. Occasional rain or drizzle.
> Moderate or good, occasionally poor.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org