> Dan York <mailto:y...@isoc.org> > 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
