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

Yunhong Gu <guu@google.com> Tue, 17 March 2015 01:07 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 7DE151ACDA8 for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 18:07:37 -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 SoYryiqU58DF for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 18:07:35 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 EBE101ACDA6 for <dnsop@ietf.org>; Mon, 16 Mar 2015 18:07:34 -0700 (PDT)
Received: by oibu204 with SMTP id u204so53170681oib.0 for <dnsop@ietf.org>; Mon, 16 Mar 2015 18:07:34 -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=fVQkqPleyIGABih81dzonajJlOD3EXM+btBp36iIpdY=; b=QNe3ZJRVIFmjYev8HUQ5G+zLGKH10eApOmwmk69wEA0TWMrbE0LHYSR1Ed62fQsMS/ PB76oRodme0w3pkUhKB0rBT6vRDL0SRJUJZSuwHeSiV5vGbrwt232ZEV9P17vJSL+nWn aXvx7TBkgsBIzGfgSYoOvPNv4Z11mbVyPiDA2KtZV8gK4NZVJjQFGgf5sjwnShqpyvcl PAQ451e53c0qfgFKJCUx2qZs56o/0fl4paR9ZFH15DGU1IE4OKeoYzOzhVUYEGRdW/B5 dcHaeM379Le5CNsGnmIrlRRBRXgnSDP4bBFd1cVzVn0viLv+qZcyH8bugxEIx95JxCnP z1mA==
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=fVQkqPleyIGABih81dzonajJlOD3EXM+btBp36iIpdY=; b=b1XzN8aqjP3WznnL8Ezqh+hno9exqRfAL37+K6DN+ngafCS8KRvqgyQ0PgEwgbw+xk Ux9MRFY08PadgRLzynmQLA/zMorz+IZ8H48M0DKwl3uLC4jWpqh0nPGP7l0MppnPV/nF XMPaes4bK2yFYp+cDrVHXTyd4u4g9pWdoYqIE6HfognznQXGXPaZOSqLmRzmmDrcRg0n THQQEUoucCc8iCyBUqxtoI/JIN6w3rYK8WhbIk5uoxTquOgJclQgTSpA9QIGFPWCxT3/ MC1IYIU8/u++u+vYNnCmAU7MsH/ANdkbTxDwYnERuFPkpUfOwxT9MilTDuP5KfZArGlA fETA==
X-Gm-Message-State: ALoCoQm3Mph3YPPsSXaXohFQDRF+oUMVkneZvJugbX7R8HleOxNV+znvOOjXYBW9Kr5kGvBCQkim
MIME-Version: 1.0
X-Received: by 10.202.197.139 with SMTP id v133mr12753545oif.1.1426554454432; Mon, 16 Mar 2015 18:07:34 -0700 (PDT)
Received: by 10.182.80.10 with HTTP; Mon, 16 Mar 2015 18:07:34 -0700 (PDT)
In-Reply-To: <55077A64.7050906@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>
Date: Mon, 16 Mar 2015 21:07:34 -0400
Message-ID: <CAGmQtQK1fa2Ji0gUzahZ4q4yJKTy9fwdRKDE+Vhe6h3ejBm=KA@mail.gmail.com>
From: Yunhong Gu <guu@google.com>
To: Michael Sinatra <michael@brokendns.net>
Content-Type: multipart/alternative; boundary=001a1134e7aa8277fa051171976f
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/ZEEdyiXZbOaqkumJObodMpjpxD0>
X-Mailman-Approved-At: Tue, 17 Mar 2015 07:28:22 -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 01:10:02 -0000

On Mon, Mar 16, 2015 at 8:50 PM, Michael Sinatra <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> 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.



>
> * 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
>
> _______________________________________________
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>