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

Paul Vixie <> Fri, 06 March 2015 21:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3CD9D1A86E2 for <>; Fri, 6 Mar 2015 13:02:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J-1biDeLKACQ for <>; Fri, 6 Mar 2015 13:02:18 -0800 (PST)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D16111A6F10 for <>; Fri, 6 Mar 2015 13:02:18 -0800 (PST)
Received: from [IPv6:2001:559:8000:cb:b015:3cb0:25ba:df77] (unknown [IPv6:2001:559:8000:cb:b015:3cb0:25ba:df77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 255401851C; Fri, 6 Mar 2015 21:02:19 +0000 (UTC)
Message-ID: <>
Date: Fri, 06 Mar 2015 13:02:16 -0800
From: Paul Vixie <>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: Dan York <>
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------070601080009030906090701"
Archived-At: <>
Cc: Simon Perreault <>, "" <>
Subject: Re: [DNSOP] More work for DNSOP :-)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Mar 2015 21:02:20 -0000

> Dan York <>
> Friday, March 06, 2015 12:13 PM
> 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

i don't want to see ANY deprecated. there are valid diagnostic uses for
it. the definition of this protocol verb should remain. the only change
we should make is that it be ACL'd to "nobody" by default.
> 2. “Meta queries” should be behind some access control mechanism

that's new work, new protocols, new implementations. while i'd like to
see that work progress, it's a large work-item and would result in a DNS
Maintainance and Diagnostic protocol, probably REST/JSON, and would drag
in DNS Provisioning, for adding slave zones or whatever. by the time we
get done accepting all the help from all the innovators who would have
strong contributions to that, we're talking a period of five to ten years.

> Separately, we can also provide guidance that other meta queries
> should be put behind some kind of access control mechanism.   My worry
> about grouping ANY with the other meta queries is that it may indicate
> to people that it is still okay to implement the ANY query.

i think that any recommendation we make that says "ANY is a meta-query"
should also state that like AXFR/IXFR and like RD=0 for recursive-only
servers, ANY should not be available to untrusted or unidentified
initiators. that would address the "is it still OK to implement?"
question in the best possible way.

Paul Vixie