I've been having some intermittent dns problems with a web server, where certain isp's dns servers don't have my hostnames in cache and fail to look them up. At the same time, queries to opendns for those hostnames resolve correctly. It's intermittent, and it always works fine for me, so it's hard to identify the problem when someone reports connectivity problems to my site.
In trying to figure this out, I've been looking at my logs to see if there are any errors I should know about.
I found thousands of the following messages in my logs, from different ip's, but all requesting similar dns records:
May 12 11:42:13 localhost named[26399]: client 94.76.107.2#36141: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:13 localhost named[26399]: client 94.76.107.2#29075: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:13 localhost named[26399]: client 94.76.107.2#47924: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:13 localhost named[26399]: client 94.76.107.2#4727: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:14 localhost named[26399]: client 94.76.107.2#16153: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:14 localhost named[26399]: client 94.76.107.2#40267: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:43:35 localhost named[26399]: client 82.209.240.241#63507: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:43:35 localhost named[26399]: client 82.209.240.241#63721: query (cache) 'burningpianos.org/MX/IN' denied
May 12 11:43:36 localhost named[26399]: client 82.209.240.241#3537: query (cache) 'burningpianos.com/MX/IN' denied
I've read of Dan Kaminsky's dns cache poisoning vulnerability (http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html), and I'm wondering if these log records are an attempt by some evildoer to attack my dns server.
There are thousands of records in my logs, all requesting "burningpianos", some for com and some for org, most looking for an mx record. There are requests from multiple ip's, but each ip will request hundreds of times per day.
So this smells to me like an attack. What is the defense against this?
I can't tell you for certain what it is, but I can tell you what it isn't:
For what it's worth, I think this is misconfiguration of those domains, although from here they appear to be offline. I can see some inconsistencies in the glue records for
burningpianos.com
- the.com
servers say that they're 209.97.196.66 and .67 - is that you?Contrary to Brad's suggestion, I would say that if possible you should actually configure your server to return a
REFUSED
response to queries for these domain names.Simply dropping the queries means that the clients at the other side will continue to retry, as appears to be happening already.
If the traffic drops when you do that, it straight away tells you that the source addresses are not spoofed, and that would reinforce the theory that it's misconfiguration.
Well it's possible you're being targeted for Kaminsky cache poisoning. These requests could be attempts to see if your DNS server is susceptible by looking for monotonically increasing query ids in your DNS server's responses. But obviously your DNS server isn't a public caching recursive name server as all the requests are denied, but such door banging is inevitable with script kiddies I suppose. As long as your name server doesn't serve public caching recursive DNS there's nothing to worry about, even if you had an old version susceptible to the Kaminsky attack.
Other possibilities include, weird misconfiguration on the part of burningpianos.com or some kind of attempted reflection attack. Both of which are annoying, but not harmful as long as you're not wasting your (or an innocent person's in the case of the reflection attack) bandwidth by sending denied replies back. I would assume since the query was denied it simply dropped the request without replying, but I'm not a bind expert so I'm not certain.
make sure
allow-query
in your bind configuration only allows the ip ranges you hope to serve your DNS information to.otherwise, start blocking the IPs that are requesting, as it seems like some sort of spam/backscatter especially if each IP is making many repeated requests.
It looks like it may be a dns attack on your server or an attempt to attach the addresses you see. It is easy to forge the udp address of the request resulting in a storm to the target server. Logging queries may make it easier to swamp your dns server, but is helpful to see this kind of activity.
You will likely want to allow-query to everyone. If you are blocking anyone then they won't be able to look up your servers. Also check that all your name-servers are serving up good data. dnscog.com can check your servers from the outside for you.
Make sure you are blocking recursion and queries from cache for outside addresses.
In regards to some servers not having your dns resolution in cache .. check the TTL of your DNS records. This is the Time To Live, and if set to a low number will result in servers not caching your records for very long.
This shouldn't though prevent them from resolving you though as they should just hit a root server and look up your DNS servers and come get an authoritative answer.
T
Just passing, but in that particular case, i found that allow-query-cache directive is the one to set to avoid this message. Add the following to your /etc/bind/named.conf.options file :
Source : https://kb.isc.org/article/AA-00503/0/Whats-the-difference-between-allow-query-cache-and-allow-recursion.html