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

Evan Hunt <each@isc.org> Fri, 06 March 2015 20:59 UTC

Return-Path: <each@isc.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 14AAB1A86EE for <dnsop@ietfa.amsl.com>; Fri, 6 Mar 2015 12:59:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.511
X-Spam-Level:
X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, 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 Zyt7c7IYxCb2 for <dnsop@ietfa.amsl.com>; Fri, 6 Mar 2015 12:59:25 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBA41A86E2 for <dnsop@ietf.org>; Fri, 6 Mar 2015 12:59:25 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 6CEE41FCAD0; Fri, 6 Mar 2015 20:59:22 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id DE7A7216C31; Fri, 6 Mar 2015 20:59:20 +0000 (UTC)
Date: Fri, 06 Mar 2015 20:59:20 +0000
From: Evan Hunt <each@isc.org>
To: Dan York <york@isoc.org>
Message-ID: <20150306205920.GA17567@isc.org>
References: <20150306145217.GA8959@nic.fr> <54F9C29E.9040408@jive.com> <54F9F90D.1020806@redbarn.org> <54F9FCD3.7010204@jive.com> <54F9FDFA.2030405@redbarn.org> <F25411A6-2CBD-4A76-949C-6E236FA87863@isoc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F25411A6-2CBD-4A76-949C-6E236FA87863@isoc.org>
User-Agent: Mutt/1.4.2.3i
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Gsncwh1UjdCHZhkOkYo-cXAcjWY>
Cc: Simon Perreault <sperreault@jive.com>, "dnsop@ietf.org" <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>
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 20:59:27 -0000

On Fri, Mar 06, 2015 at 08:13:09PM +0000, Dan York wrote:
> While I agree with this idea, I wonder if from a clarity of deployment
> point of view, as well as a speed point of view, it would be easier to
> divide this into two different documents:
> 
> 1.  Deprecate the ANY query
> 
> 2. “Meta queries” should be behind some access control mechanism
> 
> Is there anyone arguing that the ANY query should still be around?  Or can
> we agree that ANY is now a query that has outlived its usefulness and
> needs to fade away?

I use QTYPE=ANY for testing and troubleshooting quite frequently, and would
prefer to see it hidden behind an access control mechanism rather than
disabled completely.


(As an aside: I've often wondered why the DNS doesn't have *more* meta-query
types, less extensive than ANY, such as a single type covering A and AAAA.
Or, an EDNS OPT mechanism to request a list of desired types in addition to
QTYPE to be returned in the additional section (subject to packet size, rate
limiting, DNS cookie authentication, whatever).  I would guess the absence
of such conveniences to be the reason Mozilla decided to take their
regrettable shortcut.  It seems like such an obvious optimization, I'm
guessing it was talked to death before I ever started working with the DNS
and there were good reasons not to do it, but I don't actually know what
they were.)

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.