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

Jim Reid <jim@rfc1035.com> Mon, 20 March 2017 07:57 UTC

Return-Path: <jim@rfc1035.com>
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 720F01296C5 for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 00:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 0QvpZ0kaqSLY for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 00:57:10 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE8C1296C3 for <dnsop@ietf.org>; Mon, 20 Mar 2017 00:57:09 -0700 (PDT)
Received: from [IPv6:::1] (shaun.rfc1035.com [93.186.33.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPS id 985E4242125A; Mon, 20 Mar 2017 07:57:07 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <65cec05f-bb1b-cb9e-d874-a73c9c4653ac@dougbarton.us>
Date: Mon, 20 Mar 2017 07:57:05 +0000
Cc: IETF dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <87C900A0-50CA-4B65-813B-1F9D1D831380@rfc1035.com>
References: <CADyWQ+GSStfAiOs8R9Ob7+LVh0RAfPQ+AbbTFNuwsrKkO=EUWg@mail.gmail.com> <CAC94RYYir_5rKmW47XkUZoVCs5PUfWiKg4Cygyvw6pOzqC5mfA@mail.gmail.com> <d8f1076e-a635-7620-5e2b-0c70efe2c0cf@dougbarton.us> <EDDF24B8-42F6-4BCA-8162-5A5C7CDC8CA2@rfc1035.com> <65cec05f-bb1b-cb9e-d874-a73c9c4653ac@dougbarton.us>
To: Doug Barton <dougb@dougbarton.us>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bPXHoTXo9NUVmbDcM6fl6L-VHFM>
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: Mon, 20 Mar 2017 07:57:11 -0000

> On 17 Mar 2017, at 07:34, Doug Barton <dougb@dougbarton.us> wrote:
> 
> The traditional understanding of ANY == ALL is well ingrained in developers.

[Citation needed.] For bonus points, provide actual examples of commonly used code that have this misconception and the real operational (but self-inflicted) problems it causes for those applications.

> It is not at all unreasonable for them to assume that if the RR they wanted didn't come back in response to the ANY query that it does not exist; and I do not see anything in this draft that would help them understand that they need to requery (apologies if I missed it).

Why should this draft need to document stupid client behaviour or explain why it is stupid?

If you want to submit a draft that says "DNS clients shouldn't use the ANY QTYPE when they want to get a particular A/SRV/MX/whatever RRset returned" or even "DNS clients shouldn't use the ANY QTYPE", go ahead.

draft-ietf-dnsop-refuse-any is about something completely different. In case you hadn't noticed, the draft's about a server-side issue.

> On this point alone the draft's claim of being backwards compatible is wrong on its face, and as a result is nearly certain to cause far more disruption than benefit.

Nonsense! The draft isn't changing the protocol. It suggests how servers could handle one category of potentially harmful queries so that they cause less damage. Once deployed, the only thing this draft will disrupt is the impact of DDoS reflector/amplification attacks.

It's not going to make the slightest difference to idiot/lazy applications that make ANY queries instead of doing The Right Thing. They'll still be getting answers which might or might not contain the data they're looking for.