Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

Michael Sinatra <michael@brokendns.net> Tue, 17 March 2015 16:40 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 4AFFF1A8756 for <dnsop@ietfa.amsl.com>; Tue, 17 Mar 2015 09:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Qa-5J8-iCiqc for <dnsop@ietfa.amsl.com>; Tue, 17 Mar 2015 09:40:46 -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 6597A1A1A7E for <dnsop@ietf.org>; Tue, 17 Mar 2015 09:40:46 -0700 (PDT)
Received: from 10-9a-dd-b4-29-43.dhcp.lbnl.us (10-9a-dd-b4-29-43.dhcp.lbnl.us [198.128.193.108]) (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 EE61D14538; Tue, 17 Mar 2015 09:40:45 -0700 (PDT)
Message-ID: <550858FD.5050007@brokendns.net>
Date: Tue, 17 Mar 2015 09:40:29 -0700
From: Michael Sinatra <michael@brokendns.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Yunhong Gu <guu@google.com>, Michael Sinatra <michael@brokendns.net>
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> <CAGmQtQK1fa2Ji0gUzahZ4q4yJKTy9fwdRKDE+Vhe6h3ejBm=KA@mail.gmail.com> <55078075.8060803@brokendns.net> <CAGmQtQK9=47XiXS+uugev8cYgUn64S0s_fdpOiYRqVtsUinDbQ@mail.gmail.com>
In-Reply-To: <CAGmQtQK9=47XiXS+uugev8cYgUn64S0s_fdpOiYRqVtsUinDbQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/-WrtcoHI7MMGwn6ptRz3lYfWDrM>
Cc: dnsop@ietf.org, dns-operations <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 16:40:47 -0000

On 3/17/15 6:17 AM, Yunhong Gu wrote:

>     > Sounds to me this is the root cause of the problem and ANY is the just a
>     > scapegoat.
> 
>     Giving NSEC3PARAM a positive TTL would prevent my headache, but it
>     wouldn't help the victim of the attack, and would probably make it worse
>     for the victim.
> 
> 
> The reason that this response can be used for an amplification attack is
> its size, not the ANY type. A responses with 200 A records can be used
> for the same purpose. The (even deeper) root cause is the use of UDP in
> DNS protocol. I just do not think banning ANY touches any of these
> fundamental issues.

Ah, this is a different argument.

I don't believe that I ever suggested "banning" ANY.  What I suggested
is that if you want to use TC=1 to stop the current en vogue attack, you
need to apply it everywhere and make sure that all implementations
handle it the same way: All ANY responses get TC=1 with a *minimal*
response.  Not all implementations currently do that.  Another option
is cookies, although I haven't fully thought through how that would mesh
with the current attack dynamics.

I recognize you can do reflection attacks with A records, although there
are even better attacks out there that don't use ANY or A.  But ANY has
basically three uses: reflection attack, troubleshooting, and supporting
old qmail.  I'd be interested in methods that can be implemented in a
matter of weeks or months, which can reduce the attack vector, while
retaining as much of the "legitimate functionality" as possible, knowing
that the threat can't be fully eliminated.

As it stands, operators are taking matters into their own hands and
simply blocking ANY responses (which makes my headache bigger because I
slave for some of those operators and they're pushing more of the
iterative ANY queries at me).

michael