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