Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

Tony Finch <dot@dotat.at> Fri, 17 March 2017 19:38 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D21112940C for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 12:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 i8SzRMQtSGUp for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 12:38:32 -0700 (PDT)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8B91293F8 for <dnsop@ietf.org>; Fri, 17 Mar 2017 12:38:32 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:49190) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1coxhl-000DxP-1t (Exim 4.89) (return-path <dot@dotat.at>); Fri, 17 Mar 2017 19:38:29 +0000
Date: Fri, 17 Mar 2017 19:38:29 +0000
From: Tony Finch <dot@dotat.at>
To: Doug Barton <dougb@dougbarton.us>
cc: dnsop@ietf.org
In-Reply-To: <d8f1076e-a635-7620-5e2b-0c70efe2c0cf@dougbarton.us>
Message-ID: <alpine.DEB.2.11.1703171922510.13590@grey.csi.cam.ac.uk>
References: <CADyWQ+GSStfAiOs8R9Ob7+LVh0RAfPQ+AbbTFNuwsrKkO=EUWg@mail.gmail.com> <CAC94RYYir_5rKmW47XkUZoVCs5PUfWiKg4Cygyvw6pOzqC5mfA@mail.gmail.com> <d8f1076e-a635-7620-5e2b-0c70efe2c0cf@dougbarton.us>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dGqa5OsFP62FWp0N9SxZu-lYBxI>
Subject: Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 17 Mar 2017 19:38:34 -0000

Doug Barton <dougb@dougbarton.us> wrote:

> I think this is a bad idea generally, and that RRL is a better solution to the
> amplification vector issue.

RRL and minimal-any address different problems.

My servers have been using RRL for many years and it works very nicely at
dealing with spoofed UDP attacks directed at my auth servers.

I implemented and deployed minimal-any to reduce TCP overload problems.
If many legitimate recursive servers are being abused as amplifiers, using
a name hosted by my authoritative servers, my auth servers can get
overloaded with too much TCP traffic.

With minimal-any, the recursive servers get answers over UDP, populate
their caches, and go away happy.

Cloudflare's reason for deploying minimal-any is also unrelated to RRL. On
their servers it is very expensive to assemble an ANY response. It is much
simpler and cheaper for them to satisfy queries with a synthetic response
than waste effort on a traditional full-fat answer.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: Cyclonic becoming southwest, 5 or 6. Rough, occasionally
very rough. Occasional rain. Good, occasionally poor.