Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Mark Andrews <marka@isc.org> Tue, 17 March 2015 01:10 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 6904A1ACDA1 for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 18:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level:
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 38FfD98BlOEO for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 18:10:57 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47CE1ACD9E for <dnsop@ietf.org>; Mon, 16 Mar 2015 18:10:56 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 528ED1FCB1C; Tue, 17 Mar 2015 01:10:53 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 563CC160067; Tue, 17 Mar 2015 01:17:59 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-175-41.carlnfd1.nsw.optusnet.com.au [211.30.175.41]) by zmx1.isc.org (Postfix) with ESMTPSA id E4D4B160058; Tue, 17 Mar 2015 01:17:58 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B1F952B67791; Tue, 17 Mar 2015 12:10:51 +1100 (EST)
To: Michael Sinatra <michael@brokendns.net>
From: Mark Andrews <marka@isc.org>
References: <20150309110803.4516.qmail@cr.yp.to> <20150309151812.GA14897@xs.powerdns.com> <20150316142350.GB26918@xs.powerdns.com> <55075C41.9000208@brokendns.net> <13D58CB4-95BD-412B-A073-C95617E97BCE@redbarn.org> <55077A64.7050906@brokendns.net>
In-reply-to: Your message of "Mon, 16 Mar 2015 17:50:44 -0700." <55077A64.7050906@brokendns.net>
Date: Tue, 17 Mar 2015 12:10:50 +1100
Message-Id: <20150317011051.B1F952B67791@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/ZAOLV1iRy_ev-g_Oyob3tGiC39I>
Cc: dnsop@ietf.org, P Vixie <paul@redbarn.org>, bert hubert <bert.hubert@netherlabs.nl>, dns-operations@dns-oarc.net
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
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: <http://www.ietf.org/mail-archive/web/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, 17 Mar 2015 01:10:58 -0000
In message <55077A64.7050906@brokendns.net>, Michael Sinatra writes: > On 3/16/15 4:15 PM, P Vixie wrote: > > > > > > On March 17, 2015 7:42:09 AM GMT+09:00, Michael Sinatra <michael@brokendns. > net> wrote: > >> > >> > >> On 03/16/15 07:23, bert hubert wrote: > >> > >>> Separately, I fail to see why we actually need to outlaw ANY queries > >> when we > >>> can happily TC=1 them. > >> > >> If the public recursives also support TC=1 on all ANY queries, then > >> this > >> works. If not, the issue arises where just-below-the-radar attacks are > >> using many public recursives, in which case you're not stopping much. > > > > Michael, what attacks do you think we can stop by limiting ANY? Paul > > The attack that I have had to grapple with is this: > > * Someone sets up a bot to query public recursives (google, opendns, > level3, etc.) for a particular domain whose ANY response is large. > (This _usually_ means DNSSEC-signed.) > > * The query from each <client,domain,qtype> tuple is just barely slow > enough not to trigger rate limiting from the public recursive service. > > * The backend of the public recursive service queries my authoritatives > for some of the involved domains. Suppose the response is just under > the usual typical default EDNS0 buffer size of 4096. > > * These domains are DNSSEC-signed with NSEC3. Many tools set the TTL of > NSEC3PARAM to 0 when signing zones with NSEC3. The NSEC3PARAM RR is > part of the ANY response. > > * The public recursive servers use an implementation that clears all > records from the cache when the TTL of one record expires, so the next > time the recursive server gets an ANY query, it must re-query the > authoritative server. > > In this situation, if I set TC=1 for all ANY queries on my authoritative > server, but the public recursives don't, then the victim still gets hit > with a pretty big amplification attack, and my authoritative servers get > hammered with TCP queries. It's annoying for me--not insurmountable, > but annoying, as the thousands of simultaneous TCP connections require > some tuning to manage reasonably. But for the victim? Who knows--I > can't see who the victim is in this case. The more I tune my servers, > the more data gets likely thrown at the victim. > > I have seen this in the wild, even where the response is bigger than > 4096, so the TC bit should be set all around. Note also that if my > response is bigger than 4096, I'll send an empty response back with TC=1 > (I am using BIND-latest). I have seen some recursive implementations (e.g. > unbound) that will dutifully send the victim everything right up to the > next RRset that would push it over 4K and set TC=1 for good measure. So > the victim still gets a ~4000-byte UDP response, even with TC set. > > So my point is that if we're going to specify TC=1 for ANY queries, it > has to be mandatory, and all implementations have to handle it the same: > Send an empty NOERROR and set TC=1. If I am the only one setting TC=1, > it won't doing any good for the attack described above, even if my > domains are the ones being used in the attack. > > The other option is to allow the authoritative servers to control what > gets set out in response to QTYPE=ANY. But I see devils in the details, > just as with NOTIMP and other proposals. > > michael > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop Lets get DNS cookies finalised so that TC=1 isn't needed for repeat legitimate clients. There is a open question about whether the error field is needed or not and I'm of the opinion that it isn't needed. TC=1 for amplification suppression should be triggered by response size and whether you are a known repeat client or not rather than {meta} query type. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Colm MacCárthaigh
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Ted Lemon
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Mark Andrews
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Nicholas Weaver
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… David Conrad
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… bert hubert
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… bert hubert
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Ray Bellis
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… bert hubert
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Ray Bellis
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… P Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Mark Andrews
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Yunhong Gu
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Yunhong Gu
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Olafur Gudmundsson
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Florian Weimer
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] dnsop-any-notimp violates the DNS sta… Stephane Bortzmeyer
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Edward Lewis
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… bert hubert
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Jared Mauch
- [DNSOP] dnsop-any-notimp violates the DNS standar… D. J. Bernstein
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Jared Mauch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… David C Lawrence
- Re: [DNSOP] dnsop-any-notimp violates the DNS sta… John Levine
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Edward Lewis
- [DNSOP] clarification on DNSOP charter Re: [dns-o… Suzanne Woolf
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… D. J. Bernstein
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Darcy Kevin (FCA)
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Darcy Kevin (FCA)
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… D. J. Bernstein
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Graff
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Mark Andrews
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Randy Bush
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Masataka Ohta
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Morizot Timothy S
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… David Conrad
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Morizot Timothy S
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Robert Edmonds
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Nicholas Weaver
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Morizot Timothy S
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Mark Andrews
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Darcy Kevin (FCA)
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… D. J. Bernstein