Re: [DNSOP] More work for DNSOP :-)

Edward Lewis <edward.lewis@icann.org> Fri, 06 March 2015 15:28 UTC

Return-Path: <edward.lewis@icann.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 0C1041ACEA0 for <dnsop@ietfa.amsl.com>; Fri, 6 Mar 2015 07:28:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jxzRZLj5RZqE for <dnsop@ietfa.amsl.com>; Fri, 6 Mar 2015 07:28:47 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B421ACE9A for <dnsop@ietf.org>; Fri, 6 Mar 2015 07:28:47 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 6 Mar 2015 07:28:46 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 6 Mar 2015 07:28:46 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] More work for DNSOP :-)
Thread-Index: AQHQWB2VmGow3Oj1bkuvVwmqEwswBZ0PxoKA
Date: Fri, 06 Mar 2015 15:28:45 +0000
Message-ID: <D11F2B34.97E6%edward.lewis@icann.org>
References: <20150306145217.GA8959@nic.fr>
In-Reply-To: <20150306145217.GA8959@nic.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3508482521_12041311"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/1PxfZGZxP9xTTpIyNOnq5mv-VYI>
Subject: Re: [DNSOP] More work for DNSOP :-)
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: Fri, 06 Mar 2015 15:28:50 -0000

On 3/6/15, 9:52, "Stephane Bortzmeyer" <bortzmeyer@nic.fr> wrote:

>"Deprecating the DNS ANY meta-query type" (no Internet-Draft published)
>
>https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/
>
>"Today, we are announcing that we are deprecating the DNS ANY
>meta-query. In a few weeks we'll be responding to those queries with
>rcode 4 / Not Implemented."

I'm happy to see an operator take this on.  I would prefer to see an
Internet Draft covered by the Note Well be used as the basis of the
discussion. ( poke - ;) )

A few years (3 maybe) back I (along with many others) abuse of the ANY
query while previously working with a DNS hosting operator.  For a while
we took a similar step (I forget the details now, think we chose REFUSED)
but reversed course when we received inquiries to our help desk.  At that
point I began to give a series of presentations related to this issue,
including this at DNS-OARC two years ago:

https://indico.dns-oarc.net/event/0/contribution/18/material/slides/0.pdf

(The presentation had a wider scope, but treating ANY queries was one of
the motivators.)

The query type ANY is not essential to the protocol architecture and it
certainly has become a problem for operators.  (Anyone wanting all records
at a node can just ask for each specific type.)  The only obstacle to
removing them is that they are expected to be available.

We (as in the royal we) know collectively that ANY queries to
non-authoritative servers are more headache than helpful.  We berate
implementations (like a recent browser that turned on ANY queries,
immediately causing a thread on non-IETF operations lists).  Use of ANY in
gathering research data is acceptable, without ANY, there are alternative
means to gather research data.

I don't know who should take this on, reacting to "More work for DNSOP".
I'd prefer this come from operators (of which I am not now) who can add
insight into why part of the protocol ought to be "removed."