Bind: query (cache) './ANY/IN' denied - is it a DDos attack?

Solution 1:

It's hard to say definitively, but at first glance it looks like it could be an attempted reflection attack (or a test for the viability of using your server in such an attack).

The idea behind such an attack is sending queries over UDP with a spoofed source IP address to an open resolver server to generate traffic to the attack target (the host that actually has the spoofed source IP), using a query that is known to generate a large response to get high amplification of the attacker's bandwidth needed to send the queries.

Assuming that is the case, the implications are:

• You are not the actual target, rather intended to just "lend" your bandwidth. The source address is who is supposedly being attacked (or who is probing to check if your server could be used for such purposes).
• It didn't actually work. As you are denying these requests, the responses are not big like the actual response for . ANY would be. (Presumably from not allow recursion in the first place, which is good).

Regarding your feeling that it seems legitimate because one of the source IP addresses is 1.1.1.1, I would say that my instinctive reaction is the exact opposite. Seeing 1.1.1.1 as a source address for this query immediately indicates that something strange is going on:

• We know that 1.1.1.1 is anycast, which makes it an awful idea to initiate queries from this address. If you respond to a query from 1.1.1.1 your response will be routed to the closest (in a BGP sense) 1.1.1.1 instance, not the one that generated the query.
• Even ignoring the choice of source address, why would the Cloudflare public resolver ever be sending a query to your server for . ANY? You are not the authority for . and they also have no reason to forward queries to you.

That is, I think you are correct that these queries probably are "up to no good".
Now, whether it's a good idea to block traffic from these addresses, I'm not so sure. The issue here is that it opens up for easy DoS attacks. Someone can use this blocking behavior of yours to make your server stop responding to queries from arbitrary addresses, which could be abused to deny legitimate traffic.