will blocking getting hammered by cache request do anything?

Barry Margolin barmar at alum.mit.edu
Fri Mar 6 01:44:33 UTC 2009


In article <goov30$ng7$1 at sf1.isc.org>,
 "online-reg" <online-reg at enigmedia.com> wrote:

> Hi All: my 9.6.0 server is getting hammered by cache requests from a 
> specific IP (62.109.4.89) which traces back to what looks like a DSL 
> netblock in Russia:
> 
> 05-Mar-2009 12:18:01.883 queries: info: client 62.109.4.89#53157: query: . 
> IN NS +
> 05-Mar-2009 12:18:01.883 security: info: client 62.109.4.89#53157: query 
> (cache) './NS/IN' denied
> 
> I assume that this is some unpatched server (because currently I only see 
> this single IP trying to connect), but is there any way to tell the 
> difference between that and a deliberate DDOS attack?

Actually, this is almost certainly someone trying to use your server as 
part of a DNS amplification attack ON that server.  The source IP is 
spoofed, with the goal of getting lots of servers to send large replies 
to it.  But since you have recursion and query-cache disabled for 
external IPs, you're not amplifying anything.

> My subnet is on a Verizon 3Mbps static "business" DSL connection with a 
> router/firewall NAT'ing the incoming traffic.
> 
> My question is, will blocking this from the firewall in front of the box 
> help in any way to mitigate it's effect on the server? Or do I need to get 
> my upstream provider to block this IP for it to have any impact? The server 
> isn't "choking" on the volume of requests (yet), and I'm wondering if 
> blocking the requests at the border of the network would do anything 
> meaningful?

If you block it on the firewall, then the requests will never hit the 
server, so of course it will mitigate its effect on the server.  It 
won't help with the downstream bandwidth on your DSL, but it will stop 
the "REFUSED" replies from being sent back, so your upstream bandwidth 
will improve.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***



More information about the bind-users mailing list