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

Question

My syslog is getting floated with messages like

Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:09:25 xxx named[902]: client 74.74.75.74#47561 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:19 xxx named[902]: client 68.12.225.198#58807 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied
Jan 12 11:11:26 xxx named[902]: client 68.12.225.198#9414 (.): query (cache) './ANY/IN' denied

and i don't know if this is a DDoS attack or just strange behaviour of bind.

So i set up a simple fail2ban jail that blocks IPs that produce more than 20 such errors in 24h. After the weekend i checked and was astonished: More than 1000 IPs have been blocked. Including famous ones like 1.1.1.1. So this can not be right.

My server is a Debian 9 managed via Plesk Obsidian. I have no special configuration done to bind9/named (as far as i know). It is the primary ns server for all my domains.

So the question is: What can i do to protect my server against such a flood of dns queries or should i just ignore them.

Answer 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.