> On 17 Mar 2017, at 07:34, Doug Barton <do...@dougbarton.us> wrote: > > The traditional understanding of ANY == ALL is well ingrained in developers.
[Citation needed.] For bonus points, provide actual examples of commonly used code that have this misconception and the real operational (but self-inflicted) problems it causes for those applications. > It is not at all unreasonable for them to assume that if the RR they wanted > didn't come back in response to the ANY query that it does not exist; and I > do not see anything in this draft that would help them understand that they > need to requery (apologies if I missed it). Why should this draft need to document stupid client behaviour or explain why it is stupid? If you want to submit a draft that says "DNS clients shouldn't use the ANY QTYPE when they want to get a particular A/SRV/MX/whatever RRset returned" or even "DNS clients shouldn't use the ANY QTYPE", go ahead. draft-ietf-dnsop-refuse-any is about something completely different. In case you hadn't noticed, the draft's about a server-side issue. > On this point alone the draft's claim of being backwards compatible is wrong > on its face, and as a result is nearly certain to cause far more disruption > than benefit. Nonsense! The draft isn't changing the protocol. It suggests how servers could handle one category of potentially harmful queries so that they cause less damage. Once deployed, the only thing this draft will disrupt is the impact of DDoS reflector/amplification attacks. It's not going to make the slightest difference to idiot/lazy applications that make ANY queries instead of doing The Right Thing. They'll still be getting answers which might or might not contain the data they're looking for. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
