On 3/6/15, 9:52, "Stephane Bortzmeyer" <bortzme...@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."
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop