Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Yunhong Gu <guu@google.com> Tue, 17 March 2015 13:17 UTC
Return-Path: <guu@google.com>
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 460831A064C for <dnsop@ietfa.amsl.com>; Tue, 17 Mar 2015 06:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.788
X-Spam-Level:
X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gkKnHcXs3KPh for <dnsop@ietfa.amsl.com>; Tue, 17 Mar 2015 06:17:24 -0700 (PDT)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667151A049A for <dnsop@ietf.org>; Tue, 17 Mar 2015 06:17:24 -0700 (PDT)
Received: by obbgg8 with SMTP id gg8so6704543obb.1 for <dnsop@ietf.org>; Tue, 17 Mar 2015 06:17:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ff+orN9Q3KZkNMJBPeRpuAj29VHjLHhBbRxkDM2+KMk=; b=Ky49RahstOjx2L3kG8mFLj2IUz5jYUuLZLoKSEMHa6o39a7WZVHe3BsOsJO3OZCELl qnIZTqL07gW72WEEF160ZUif9tzi+mp1IZa6XTHks4dLk+0COsiWfx91VydzAft4MDUG c55gW1xQLwemmEeHCXZzQNQkxH4birx2vbjdWAAw8qQmH+Z+OioaNUEqjBY3Y7yWUzDo vTJk/ApvEv3gfQdj99Bn30xCX30pGAf1I7AYCLxiN5L9D/KWPmVFD7MDz/bgpceASOzx v4S8jwKp6DwxThX6CM3VOvQC8A0+F3I2YvaGUiZJ4jksZUuN6O8LLuhprSUp3/xFHD9e YKig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ff+orN9Q3KZkNMJBPeRpuAj29VHjLHhBbRxkDM2+KMk=; b=DRny0sIG+Hc9ydgt92bze+y4evGkXv+jldWNPTiQERYSk4lacOMfl8xM3cHQn/t/cY XqUsMxcdra5mJdQCSvWSvZIAMSHszBzyvOrP2GdFALeZPTQFhCc9MaJ4BcNygpDgcd2e PtLgzGzvTS/se8zrYvAxs5E9pJRr5oQ7B6hkHXNHBQ5jkwkDQRTqo01Q+xR4h9guO3q0 8Jq79fi7SKmfopCRKW74KpIczQNVbDSeOctOe/egG2m/ZMTzH45xscXdBAtghJPrXvnp rWStZyTGQHl/nWE+CkmQ5QcUD+owIKtCapkPQzZtSleHipRPhuLiCYryspfN8jTZLCle 7v4g==
X-Gm-Message-State: ALoCoQl8NhbKYyPLD2f9CdN/Wlwoj+Fdq2JQ91joIpnd0N1Szx7g3HPzmyaI2KoGV7mC5DEbKWCW
MIME-Version: 1.0
X-Received: by 10.202.77.198 with SMTP id a189mr11451242oib.49.1426598243897; Tue, 17 Mar 2015 06:17:23 -0700 (PDT)
Received: by 10.182.80.10 with HTTP; Tue, 17 Mar 2015 06:17:23 -0700 (PDT)
In-Reply-To: <55078075.8060803@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>
Date: Tue, 17 Mar 2015 09:17:23 -0400
Message-ID: <CAGmQtQK9=47XiXS+uugev8cYgUn64S0s_fdpOiYRqVtsUinDbQ@mail.gmail.com>
From: Yunhong Gu <guu@google.com>
To: Michael Sinatra <michael@brokendns.net>
Content-Type: multipart/alternative; boundary="001a1134fdc890c1cf05117bc960"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/75CAuhjgFwyUcHjtjBO8KqULS-Q>
X-Mailman-Approved-At: Tue, 17 Mar 2015 07:28:25 -0700
Cc: dnsop@ietf.org, P Vixie <paul@redbarn.org>, bert hubert <bert.hubert@netherlabs.nl>, 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 13:17:26 -0000
On Mon, Mar 16, 2015 at 9:16 PM, Michael Sinatra <michael@brokendns.net> wrote: > > > On 03/16/15 18:07, Yunhong Gu wrote: > > > > > > On Mon, Mar 16, 2015 at 8:50 PM, Michael Sinatra <michael@brokendns.net > > <mailto:michael@brokendns.net>> wrote: > > > > 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 <mailto: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. > > > > > > 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. > > 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