Debugging a DNSmasq server using it's logs, I find a LOT of:

dnsmasq: query[ANY] . from RANDOM-IP
dnsmasq: query[ANY] . from RANDOM-IP
dnsmasq: query[ANY] . from RANDOM-IP
dnsmasq: query[ANY] . from RANDOM-IP

All legitimate queries seem to be more specific, like:

dnsmasq: query[A] specificdomain.com from KNOWN-IP

EDIT: This is NOT intended as a public DNS service

We want to create a white-list DNS filter, it should ONLY answer to a list of specified domains. Typical amplification attacks would only affect our server, nobody else. We just want a cleaner log to be able to operate better.

The intended operation is:

  • Client uses this DNS for their internet connection.
  • Client requests domain resolution
  • If the domain is in the white-list, we resolve, if not, we don't reply.

How can we achieve this? Only process request that match our white-list, discard anything else.


. ANY is a well-known query that requests all record types in cache that are associated with the root node (AKA .) of DNS. In high volume this assuredly an indicator of malicious behavior. Unfortunately, these queries are almost certainly UDP, and the source IP is the spoofed source address of the victim.

This problem needs to be addressed by identifying why malicious entities are able to make these requests against your server, and not by blocking the query itself. The attackers can just as easily leverage any number of requests known to return large result sets, some of which do not use the record type ANY at all.

In most cases, this is an indicator that you are running an open resolver. Your first priority should be to confirm this and close the security vulnerability. If you are not an open resolver, there is an infected device on your network. This becomes harder to track as you need to trace the MAC address one hop at a time back to the origin device.

  • thanks for the info, since it is a public cache DNS (for filtering), how can the server protect itself from it? – mencargo Apr 5 '17 at 20:13
  • You should not be running a public cache if your infrastructure was not designed with abuse in mind. We have a summary of the challenges involved here. – Andrew B Apr 5 '17 at 20:21
  • It's not the case mate (explained in edit), please remove the duplicate mark. – mencargo Apr 6 '17 at 22:22
  • I'm getting mixed messages here. If that was indeed the setup, asking how to protect yourself from ANY queries directed at the root zone doesn't make much sense. I'll remove the dupe flag, but it sounds like you need to provide as much detail as possible in regards to your atypical setup. – Andrew B Apr 6 '17 at 22:29
  • More details provided, glad to respond any question about it – mencargo Apr 7 '17 at 0:47

Although, as pointed out by Andrew, there are many security concerns about a DNS service in a public IP, the solution was the following iptables rule:

iptables -A INPUT -i eth0 -p udp --dport 53 -m string --hex-string "|0000ff|" --algo bm -j DROP

That specifically drops that query.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.