Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: DNS queries for "." - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
DNS queries for "."

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.

If you are also seeing these queries and have a better explanation (or a good guess :) what is going on, please let us know.

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. 

Daniel

367 Posts
ISC Handler
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?
Ken

40 Posts
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...
Matt

7 Posts
I take it that DJB would love seeing mentioned that tinydns - unless explicitly set up to do so - does not answer such requests.
rpdenid

3 Posts
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.
Dshield

10 Posts
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.
tyldis

5 Posts
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
Anonymous
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.
Torsten

3 Posts
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..
Paul

13 Posts
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.
Ken

40 Posts
It was only temporary... As of about an hour later, 13:32 UTC, I'm seeing alerts on these again.
Ken

40 Posts
On Jan 20, 2009 I'm seeing that the targets tailed off and the new spoofed IP addresses are:

66.230.160.1
66.230.128.15

which also are IP addresses related to a porn site.
Andrew

41 Posts
Looking for a quick fix. Using BIND9; have disabled all recursion and it now (correctly) won't resolve non-authoritative hosts - instead it returns the root hints and I don't know how to stop this!

Thanks
Anonymous
for an authoritative (only) name server, replying with the list of root name servers when asked for a domain it is not authoritative for, is the normal reaction. So, I would say the name server replies to the query "NS .", but rather, the name server says to "ask them (the root name servers)".

This being said, the problem remains that there is a multiplication factor of *10 ... *15 (45 bytes in - I didn't count them, 500+ bytes out).
To reduce that multiplication factor, one could consider using a dedicated view (Bind 9) to hold authoritative data, and within that view use a different (short) list of root name servers : namely with only that authoritative name server itself. That would probably reduce the amplification factor to max 2. "innocent" name servers that accidentily ask there question, should ignore that list of root name servers anyway ...

Kind regards,

Marc Lampo
author and teacher of
"DNS Explained" at John Cordier Academy, Belgium
Anonymous
Thanks
Anonymous
There isn't a quick fix yet. I posted the above length 45, which is the datagram length. The packet length was, originally, 60 and the payload length is 17. It all depends on which bit of the UDP packet your firewall matches against. All of this can be had from tcpdump and the man pages for your firewall. <br> The easiest "fix" is to use something like snort_inline and the rule Ken posted earlier in block or sblock mode. You may want to increase the logging frequency in the rule if you use block or newsyslog is going to be busy. snort_inline is ideal if you're running iptables or ipfw. You can also use allow-recursive and allow-query-cache in BIND with IP ranges to limit recursive queries to a known subset of hosts, but in this case the target is still having to deal with your recursive refusal reply which, ironically, is the same length as the query. You can also try snortsam with Ken's rule, which works with a wider range of firewall packages, but has the disadvantage that it installs permanent block rules and is a possible DoS vector against your own network. The snort solutions are about the best you're going to get. <br> Be aware that the targets are changing (I have about six in my logs now) so simply blocking on source address is not sufficient. I can confirm that the snort rule SID: 20090030 from Emerging Threats works without hindering legitimate traffic.
Matt

7 Posts
If your Bind 9 is authoritative-only, globally deny queries and recursion (in the options section), and then allow queries in each zone definition. Queries for the \".\" hint zone are implicitly denied.
Alex2k

3 Posts
new target is 63.217.28.226 which is listed within SpamHaus as SBL Ref: SBL68873 netblock 63.217.28.128/25 as a Russian & Polish pharmacy spam operation
Andrew

41 Posts
Started receiving queries from 206.71.158.30 around 18:26 UTC (01/24/2009).
Dshield

10 Posts
Have been seeing this for several weeks from all the mentioned IP's. If you are using the Cisco IPS sensors, the 4003/0 sig fires. The "quick" fix for us has been to simply block inbound traffic at the firewall from the IP address being spoofed until the attack stops.
Dshield
6 Posts
Checked my logs this morning and 3 more addresses show up: 67.192.144.0 (rackspace); 64.57.246.146 (4T Networks); 208.69.32.12 (OpenDNS). Looks like the Denial of Service attack is spreading/migrating.
Dshield
2 Posts

Sign Up for Free or Log In to start participating in the conversation!