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

Paul Wouters <paul@nohats.ca> Wed, 18 March 2015 13:58 UTC

Return-Path: <paul@nohats.ca>
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 B9B961A0250 for <dnsop@ietfa.amsl.com>; Wed, 18 Mar 2015 06:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mCVPeqk1H-DP for <dnsop@ietfa.amsl.com>; Wed, 18 Mar 2015 06:58:11 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216691A01F4 for <dnsop@ietf.org>; Wed, 18 Mar 2015 06:58:11 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l6Xy83Wy0z7SB; Wed, 18 Mar 2015 14:58:08 +0100 (CET)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=ebE5oyQy
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id HeOHprwuGrl5; Wed, 18 Mar 2015 14:58:07 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 18 Mar 2015 14:58:07 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AB3F5819A0; Wed, 18 Mar 2015 09:58:05 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426687085; bh=WPkqwNsfh0n+PhMem13xCOQ4snSSylCa3cXt/+NyJXg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ebE5oyQy0RdEpIiwOqH0Ez7At15/2qvOe9/qcaIbNEJiLmt6iDqBoxgCA7RfP8GYj SroEo0Wth+RNSG69po9oZ8x/XSMIsAcEqERt23hv/et/gxJWsykURXOAhGdcMSD8GF Q/bkOmzEON+t0wyghnLi/n7OGFV+FDvP2jXW7ceA=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2IDw4L6021419; Wed, 18 Mar 2015 09:58:05 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Wed, 18 Mar 2015 09:58:04 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Paul Vixie <paul@redbarn.org>
In-Reply-To: <55092A1E.50405@redbarn.org>
Message-ID: <alpine.LFD.2.10.1503180944580.23034@bofh.nohats.ca>
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> <alpine.LFD.2.10.1503170933130.25684@bofh.nohats.ca> <55092A1E.50405@redbarn.org>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/8CXQYSRHV8rPR6XekcRHmHzN59Q>
Cc: dnsop <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 13:58:13 -0000

On Wed, 18 Mar 2015, Paul Vixie wrote:

> Paul Wouters wrote:
>       On Tue, 17 Mar 2015, Yunhong Gu wrote:
>
>             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.
>
>       Right, so require tcp or eastlake cookies,
> 
> that would protect third parties, but not the server itself.

It offers some protection, but it is not perfect.

>       or allow padding the ANY
>       request so the request/response ratio is close to 1 before allowing
>       the answer.
> 
> that would not prevent the unfortunate information leak that allows third parties to scan our caches.

So there are two clear distinct use cases. ANY against authoritative and
ANY against caches. I agree that one could limit ANY queries of caches
to a sysadmin only ACL. We lose some remote debugging capability but
gain some privacy. Putting an ACL in on the authoritative server is
much more complex - it could backfire as a long discussion in the last
week on how to refuse those queries show.

>       Make the dig command default to tcp. That should cover
>       the vast majority of valid ANY queries.
> 
> my proposal is, limit ANY to a selected set of source-ip addresses, as is commonly done with AXFR/IXFR.

Which I answered before by saying that is basically killing the ANY
query. The proposed solution merely pretends to not kill it by saying
"acl". But let me clarify that I think putting an ACL on the recursive
is fine - legitimate applications should not use use ANY queries and
this is a fine mechanism to ensure the qmail's and firefoxes of the
future won't make the same mistake.

The trick of requiring ANY comes via verified sourc IP or a question
packet bigger than the response ensures this query type will cease to
be used for amplification. If we want to do this we should start changing
our legitimate tools to do this so at some point in the future we
could enforce this without breaking our own toolbox.

Paul