Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Michael Sinatra <michael@brokendns.net> Wed, 18 March 2015 08:11 UTC
Return-Path: <michael@brokendns.net>
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 CFE591A00D8 for <dnsop@ietfa.amsl.com>; Wed, 18 Mar 2015 01:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.589
X-Spam-Level:
X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_45=0.6, 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 HYVbtEc8r_z4 for <dnsop@ietfa.amsl.com>; Wed, 18 Mar 2015 01:11:51 -0700 (PDT)
Received: from elwha.brokendns.net (elwha.brokendns.net [206.125.172.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BD41A00F0 for <dnsop@ietf.org>; Wed, 18 Mar 2015 01:11:51 -0700 (PDT)
Received: from sponge.burnttofu.net (unknown [IPv6:2601:9:4400:5500::2222]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elwha.brokendns.net (5.65c/IDA-1.4.4/5.63) with ESMTPSA id 5F3F4145F1; Wed, 18 Mar 2015 01:11:51 -0700 (PDT)
Message-ID: <55093346.2050005@brokendns.net>
Date: Wed, 18 Mar 2015 01:11:50 -0700
From: Michael Sinatra <michael@brokendns.net>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Paul Vixie <paul@redbarn.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> <5507CA2B.5000206@redbarn.org>
In-Reply-To: <5507CA2B.5000206@redbarn.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/gD5nZDWFeAydh49s-RTeX7bMY4s>
Cc: dnsop@ietf.org
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: Wed, 18 Mar 2015 08:11:53 -0000
On 03/16/15 23:31, Paul Vixie wrote: > removing dns-operations@ as a cc. one mailing list at a time, please? Sorry, saw this response late... > Michael Sinatra wrote: >> On 3/16/15 4:15 PM, P Vixie wrote: >>> > Michael, what attacks do you think we can stop by limiting ANY? Paul >> ... >> >> * 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. > > well, that's part of your problem right there. but i can see how ANY is > involved, now. Right, there have been discussions on this in the past (I think on dns-operations@), but both BIND (dnssec-signzone) and the OpenDNSSEC tools set the NSEC3PARAM TTL to 0. I am not sure what the "right" answer is, but it is contributing to the problem below. > this is an internet-affecting bug and i hope you report it as such. > RRsets are to be purged when the lowest TTL therein expires, but the > other RRsets sharing that name should not be affected. can i ask which > public facing dns service has mandated that the rest of us juggle their > chainsaws for them in this way? (this is even worse than the jerk who > decided that EDNS could use IP fragmentation -- but i think that guy has > apologized at least.) I know unbound did do this--I think it still does, but it's late and I haven't had a chance to test it. The public recursive DNS service was google, and again, my tests six months ago showed that they were purging the entire ANY pseudo-RRset and requerying the authoritative servers. > "hammered" sounds like a volume greater than that which would be > detected and strangled with DNS RRL. what am i missing here, that makes > this your problem, rather than the public recursive dns operator's problem? I think there are a few issues at play. google and other public recursives will sometimes have multiple backend servers fetch a given RR when they receive a single query for that RR on one instance of, say, 8.8.8.8. I am basing this both on observed behavior and on Geoff Huston's research (recently presented at NANOG). And since nothing is cached, I get the same servers asking the same query over and over again. Writ large, the result is that I end up with 1-2k of simultaneous TCP sessions, per server, per domain. Nothing I can't handle, since usually only 2-3 of my domains are involved, But it does mean that I have to tweak BIND's defaults, since the number of allowed simultaneous TCP sessions for that implementation is much lower. Otherwise I deny legitimate clients, since the TCP limit is applied across the entire named process, without regard to QTYPE or anything else. So if someone is good at figuring out where the rate limits lie, and what tuple(s) they're based on, they can try to sneak just under the radar of any public cache, not just google. If they spread the tuple values out enough, they might have an effective attack. I have no idea how debilitating it is, as I have no visibility into who the actual victim is in this case. > i think there's no saving ANY at this point. we're deciding how it dies > and where to bury it, that's all. > > however, you've provided an example of an ANY attack that can't be > trivially switch to TXT, so, thank you. I am pretty small-time, but given some of the domains I slave are viewed as useful for reflection attacks, I will usually see these odd things when they crop up. michael
- 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