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

Dan York <> Fri, 06 March 2015 20:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B54EA1A1AF0 for <>; Fri, 6 Mar 2015 12:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zygwysBxygOF for <>; Fri, 6 Mar 2015 12:13:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 384591A6F12 for <>; Fri, 6 Mar 2015 12:13:18 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 6 Mar 2015 20:13:10 +0000
Received: from ([]) by ([]) with mapi id 15.01.0099.004; Fri, 6 Mar 2015 20:13:10 +0000
From: Dan York <>
To: Paul Vixie <>
Thread-Topic: [DNSOP] More work for DNSOP :-)
Date: Fri, 06 Mar 2015 20:13:09 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
authentication-results:; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB820;
x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10009020)(377454003)(24454002)(93886004)(2656002)(87936001)(83716003)(36756003)(82746002)(33656002)(99286002)(19580405001)(86362001)(76176999)(54356999)(50986999)(77156002)(62966003)(19617315012)(66066001)(2900100001)(102836002)(15975445007)(77096005)(15395725005)(16236675004)(122556002)(40100003)(92566002)(2950100001)(46102003)(19580395003)(110136001)(106116001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB820;; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BLUPR06MB820; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB820;
x-forefront-prvs: 05079D8470
Content-Type: multipart/alternative; boundary="_000_F25411A62CBD4A76949C6E236FA87863isocorg_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2015 20:13:09.7856 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB820
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 20:13:20 -0000

On Mar 6, 2015, at 1:20 PM, Paul Vixie <<>> wrote:

i now realize that the draft should cover "meta queries" in general, including RD=0 to a recursive server, AXFR and IXFR, and ANY of course, and whatever else we can come up with. and the recommendation should be to place these query types behind some access control mechanism, to prevent them from being used in normal DNS operations, but to support their use for diagnostic or other close-relationship activities (zone transfers).

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 say that because I think if we agree ANY should go, we should be extremely clear about that and, as Simon said, break ANY significantly so that people stop relying on it and stop supporting it in DNS clients and applications.  Get rid of it.

And provide that guidance in an extremely simple and clear manner.    (Realizing, of course, that all we can do is make the recommendation and encourage operators and app developers to follow that recommendation.)

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.

My 2 cents,

Dan York
Senior Content Strategist, Internet Society<>   +1-802-735-1624
Skype: danyork