> 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

Reply via email to