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

Tony Finch <dot@dotat.at> Fri, 05 February 2016 22:10 UTC

Return-Path: <fanf2@hermes.cam.ac.uk>
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 C76641B2E10 for <dnsop@ietfa.amsl.com>; Fri, 5 Feb 2016 14:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 caYeXnEfHF_k for <dnsop@ietfa.amsl.com>; Fri, 5 Feb 2016 14:10:10 -0800 (PST)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 44CE71B2E0D for <dnsop@ietf.org>; Fri, 5 Feb 2016 14:10:10 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41520) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1aRoZs-000Jfn-h1 (Exim 4.86_36-e07b163) for dnsop@ietf.org (return-path <fanf2@hermes.cam.ac.uk>); Fri, 05 Feb 2016 22:10:08 +0000
Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1aRoZs-0004QK-A7 (Exim 4.72) for dnsop@ietf.org (return-path <fanf2@hermes.cam.ac.uk>); Fri, 05 Feb 2016 22:10:08 +0000
Date: Fri, 5 Feb 2016 22:10:08 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: dnsop@ietf.org
Message-ID: <alpine.LSU.2.00.1602052158390.7000@hermes-2.csi.cam.ac.uk>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/fjLIMnfN0waIT6QjfEnYteDVftc>
Subject: [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:10:12 -0000

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.

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.