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

Jim Reid <jim@rfc1035.com> Sat, 18 March 2017 04:13 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 B746F12954D for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 21:13:15 -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 KtFckud2ji2G for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 21:13:14 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8ED129526 for <dnsop@ietf.org>; Fri, 17 Mar 2017 21:13:13 -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 9D835242125A; Sat, 18 Mar 2017 04:13:10 +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: <1f14d1bb-ba25-0569-c73b-f167d4fb43d3@dougbarton.us>
Date: Sat, 18 Mar 2017 04:13:08 +0000
Cc: IETF dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A8543100-0F0A-43EA-AB54-C92DB33FC7DE@rfc1035.com>
References: <d8f1076e-a635-7620-5e2b-0c70efe2c0cf@dougbarton.us> <EDDF24B8-42F6-4BCA-8162-5A5C7CDC8CA2@rfc1035.com> <65cec05f-bb1b-cb9e-d874-a73c9c4653ac@dougbarton.us> <20170317.112234.1061898802480941262.he@uninett.no> <1f14d1bb-ba25-0569-c73b-f167d4fb43d3@dougbarton.us>
To: Doug Barton <dougb@dougbarton.us>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BlzCFYfCfdhv7UtngZcYLU0B1hk>
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: Sat, 18 Mar 2017 04:13:16 -0000

> On 17 Mar 2017, at 17:19, Doug Barton <dougb@dougbarton.us> wrote:
> 
> I'm aware that a lot of the animosity towards ANY has come from Dan's choice of using it to find records for qmail. I am not a Dan-fan generally, but on this topic he has made the excellent point that the query exists, and has well-defined semantics which meet the use case, so it's legal to use it.

The behaviour of qmail or whatever is irrelevant to this draft and the WG. Your introduction of personalities is both irrelevant and inappropriate too.

You seem to be advocating a further change or changes to the protocol. Changes that have much more complex implications and semantics:

"If something gets an ANY response that does not include the thing it really needs, how is it supposed to know that it needs to ask again?"

and

"I'd rather see this flipped, with auth servers encouraged to include a brief explanation, or even a URL that explains the issue."

If so, that's what I am objecting to. First, it's not needed. Second, it won't solve your perceived problem. Broken DNS implementations are not going to support your proposed potential protocol change and will continue to be broken. Third, the solution for these broken implementations already exists: just make explicit queries for the desired RRtypes instead of using ANY, just like they should have been doing anyway. It's that simple.

draft-ietf-dnsop-refuse-any is fine as-is. [Well, apart from the language nit at 4.3: "returning all of CNAME" should be "returning all CNAME".] Leave it alone. Let's get this RFC out the door. It's a pragmatic and timely solution to a real operational problem that needs to be fixed.