Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

6 Answers 6

up vote 2 down vote accepted

I can't tell you for certain what it is, but I can tell you what it isn't:

  1. It isn't a Kaminsky / cache poisoning attack.
    • Kaminsky attacks require a random "nonce" on the front of the queried domain name
    • Your server is authoritative, not caching
  2. It's not high enough volume to be a reflection attack against the third party IP addresses

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.

share|improve this answer
    
When I asked whois about burningpianos.com, they gave me ns.akivatech.com as their nameserver. When I asked whois about ns.akivatech.com, it gave my ip address. These are the glue records you mentioned. Sadly I don't think plesk makes it easy to refuse queries. I'll have to do more research on that. –  Mnebuerquo May 13 '10 at 17:52
    
the good news is that if 209.67.196.66 is yours then you're already returning REFUSED - however not sure why then you're getting repeated queries. –  Alnitak May 13 '10 at 20:38
    
I disagree. No response should be sent. Why? Because it could be an reflective attack as I mentioned. Forge the source address of the packet to be your victim and send it to a bunch of DNS servers. Bam, DDoS. I'm not saying this is what that is. But being a good Internet citizen means not sending unneeded traffic. If they keep requesting, they are the ones that need to stop. Whether it's a misconfiguration or an attack, it garners utterly no need of a response from you. –  Brad May 14 '10 at 1:42
    
@Brad - this traffic is not spoofed, it's down to misconfiguration. Returning a response will 1) immediately tell the client resolver that there's a problem, and 2) not returning a response could easily triple the inbound traffic to his server. –  Alnitak May 14 '10 at 7:17

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 :

// only localhot can query cached recursive dns entries
allow-query-cache { 127.0.0.1 };

Source : https://kb.isc.org/article/AA-00503/0/Whats-the-difference-between-allow-query-cache-and-allow-recursion.html

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
good point, burningpianos could be referencing your DNS servers as their DNS servers, which would create many lookups. –  cpbills May 13 '10 at 6:25
    
definitely not a Kaminsky attack - that requires random data to be prefixed to the front of each query. –  Alnitak May 13 '10 at 11:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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