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.
Best Answer
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:
. 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. Seeing1.1.1.1
as a source address for this query immediately indicates that something strange is going on:1.1.1.1
is anycast, which makes it an awful idea to initiate queries from this address. If you respond to a query from1.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.. 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.