> On 17 Mar 2017, at 17:19, Doug Barton <[email protected]> wrote: > > I'm aware that a lot of the animosity towards ANY has come from Dan's choice > of using it to find records for qmail. I am not a Dan-fan generally, but on > this topic he has made the excellent point that the query exists, and has > well-defined semantics which meet the use case, so it's legal to use it.
The behaviour of qmail or whatever is irrelevant to this draft and the WG. Your introduction of personalities is both irrelevant and inappropriate too. You seem to be advocating a further change or changes to the protocol. Changes that have much more complex implications and semantics: "If something gets an ANY response that does not include the thing it really needs, how is it supposed to know that it needs to ask again?" and "I'd rather see this flipped, with auth servers encouraged to include a brief explanation, or even a URL that explains the issue." If so, that's what I am objecting to. First, it's not needed. Second, it won't solve your perceived problem. Broken DNS implementations are not going to support your proposed potential protocol change and will continue to be broken. Third, the solution for these broken implementations already exists: just make explicit queries for the desired RRtypes instead of using ANY, just like they should have been doing anyway. It's that simple. draft-ietf-dnsop-refuse-any is fine as-is. [Well, apart from the language nit at 4.3: "returning all of CNAME" should be "returning all CNAME".] Leave it alone. Let's get this RFC out the door. It's a pragmatic and timely solution to a real operational problem that needs to be fixed. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
