IETF Logo Mail Archive

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

Paul Vixie <paul@redbarn.org> Tue, 17 March 2015 06:15 UTC

Return-Path: <paul@redbarn.org>
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 E635A1A0070 for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 23:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.506
X-Spam-Level:
X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, 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 mbLnQWGuVBY8 for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 23:15:21 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DEC11A006F for <dnsop@ietf.org>; Mon, 16 Mar 2015 23:15:21 -0700 (PDT)
Received: from [10.64.186.6] (unknown [124.127.168.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C84111814C; Tue, 17 Mar 2015 06:15:13 +0000 (UTC)
Message-ID: <5507C66B.8020407@redbarn.org>
Date: Tue, 17 Mar 2015 15:15:07 +0900
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: Mark Andrews <marka@isc.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> <20150317011051.B1F952B67791@rock.dv.isc.org>
In-Reply-To: <20150317011051.B1F952B67791@rock.dv.isc.org>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------020000060400050200020105"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/hq0Chc29rf6gPtUrGmG4xJTDsfY>
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: Tue, 17 Mar 2015 06:15:22 -0000

note: replying only to dnsop@. no thread is ever appropriate for dnsop@
plus some other mailing list. please stop cc'ing dns-operations@ on your
replies; this is not an operational thread, and the people in the dns
community who care about protocol development, are probably on both lists.

> Mark Andrews <mailto:marka@isc.org>
> Tuesday, March 17, 2015 10:10 AM
>
> Lets get DNS cookies finalised so that TC=1 isn't needed for repeat
> legitimate clients. ...
>
> TC=1 for amplification suppression should be triggered by response
> size and whether you are a known repeat client or not rather than
> {meta} query type.

to be clear, response rate limiting will still be necessary even with
dns cookies in place.

without dns cookies, the requests don't have to have correct source-ip
addresses, and thus, a dns server can be made to attack the apparent
source of those queries. rrl helps with this.

with dns cookies, the requests have to have correct source-ip addresses,
and thus, a dns server can be made to attack its own upstream
infrastructure. rrl helps with this, also.

there should of course be more strict rate limits in place for the
former, than for the latter.

-- 
Paul Vixie

v2.23.0 | Report a Bug | By Email