DNS queries for

Published: 2009-01-18
Last Updated: 2009-01-22 19:48:29 UTC
by Daniel Wesemann (Version: 6)
51 comment(s)

Several folks are reporting odd queries hitting their DNS servers at a steady rate of about two per second.  The queries invariably ask for the name server of the domain "." (NS query for a single dot).   Since "." is a query for the root name servers, it has a very short query packet but a pretty long answer. Our current theory therefore is that this is a denial of service (DoS) attack in progress, where the DNS servers are used as "amplifiers" and unwittingly flood the (spoofed) source by providing a long answer to a system which never asked.

Update 0118 UTC: Correlations of logs and captures submitted by readers suggests that 69.50.142.11 and 76.9.16.171 are the two IPs from which most queries appear to originate... which would mean that these two sites are under a DoS attack.  ISC reader Chris used reverse DNS/passive DNS to determine that both IP addresses seem to be associated with porn sites.

Update 0253 UTC: The NOC of one of the netblocks has confirmed to ISC reader Steven that a DDoS attack is in progress against one of their clients. If you have queries for "." in your DNS log, best verify by use of a sniffer whether your DNS server actually responds and contributes to the DOS.  Normally, an internet-facing authoritative DNS server should not respond to recursive 3rd party queries, but we have received reports that some servers apparently respond to these "." queries even when recursion is disabled.

Update 1150 UTC: Several readers wrote in to comment that the answer to a "." query can come from the root-hints file or from the cache of the server itself. BIND has several options to control this behaviour (additional-from-auth, additional-from-cache, allow-query-cache).

Update 1520 UTC: 76.9.31.42,  69.50.142.110 and a couple more IPs are also being spoofed. Looks like more targets are being added into the fray.

Update 2117 UTC: We now provide an online tool on isc.sans.org that you can use to verify if your DNS server responds to these "." queries with a full list of root name servers and thus potentially contributes to the ongoing DDoS attack.  You can do this test readily on your own by issuing a "dig . NS @yournameserver" command, but since you need to run this from outside of your network to get the "real" picture, we are providing the online tool to help out.

Update: If you're looking for advice on securing your DNS servers, here's are configuration guidelines for BIND (thanks for the pointer, Hal Pomeranz!) and for Microsoft DNS.

Keywords: dns
51 comment(s)

Comments

brief experimentation with my own nameservers seems to indicate that if you don't allow recursion for queries from external hosts, this theory falls over... or am i missing something?
Seems to be a fixed length query. After putting both feet in my mouth and reporting it to an abuse@ without thinking about UDP spoofs (and got a really good reply, I might add), filtering on UDP dest port 53 with packet length 45 seems to stop it dead. For now, until whoever is pulling this DDoS stunt changes the query...
I take it that DJB would love seeing mentioned that tinydns - unless explicitly set up to do so - does not answer such requests.
So far, I've been getting these queries from 76.9.31.42, 76.9.16.171, 69.50.142.110, and 69.50.142.11. It started on Jan 16 with 69.50.142.11.
It started with a few probes from 63.217.28.226 on the 6th of Januar, then I see a lot of requests from 216.201.82.19 on the 8th of January before the real flooding for the mentioned IPs hit my server at 15th of January at 12:26:37 UTC.
I am also being hit by this.

I have blocked port 53 for packets for size 45, but named is still not working.

any other ways to block this ?

My firewall rule :
iptables -I INPUT 2 -p udp --dport 53 -m length --length 45:45 -j DROP
Getting hit by most of the listed ips too. \"Solved\" the issue by a new regex for fail2ban (bans after 10 failures of regex \"Not authoritative for(.*), sending servfail to <HOST>(.*)\" - this regex works for powerdns.
Its a dynamic solution, so you dont need to update iptables rules by hand on any new ip involved.
We had an misconfigured Windows 2008 DNS server serving the queries from spoofed addresses. I did by the instructions from Microsoft and set the option "Disable recursion" (as was set on our other servers). I used "Clear Cache" from DNS managment console, restarted the service (not the server).

After doing this I found out that the server was still happily serving the spoofed queries with root hints.

After spending an hour between banging my head to a wall, trying to figure out what I was doing wrong and restarting services ... I found out that there was a windowssystem32dnscache.dns file which contained nothing but the root hints. After uncommenting the lines, the server stopped serving the root hints and started to work as it should.

I do not know if restarting the physical server would have helped, but I didn't have this luxury of an option available..

Just to let others know that if they stumble into the same problem.. uncomment the lines or maybe rename the file..
EmergingThreats now has a snort sig to alert on this, sid:2009030. That was added to my ruleset at 7:00 UTC today. Although no servers here are responding, I have seen ~100 queries per hour from the four addresses mentioned by Dshield. As of 12:35 UTC, all have ceased.
It was only temporary... As of about an hour later, 13:32 UTC, I'm seeing alerts on these again.

Diary Archives