Blocking DoS on Bind9 - BIND mitigating abuseware traffic

Kevin Darcy kcd at
Fri Sep 7 00:47:34 UTC 2007

The "blackhole" statement is an effective tool to use for a limited 
number of misconfigured/malicious clients. It causes all requests from a 
given address or range to be ignored. The packets are still picked up 
from the listen queue (thus it doesn't help against 
packet-saturation-type attacks), but only minimally processed by named 
and no responses will be sent. It's not very scalable to large number of 
clients, though, especially since you need to reload every time the 
blackhole list changes...

                     - Kevin

Fr34k wrote:
> Hello List,
>   What other tips/suggestions/options do we have to help deal with abuseware traffic?
>   I am aware of limiting recursive queries to authorized hosts via allow-query/allow-recursion, which is helpful in limiting exposure. However, consider authorized hosts.
>   For example, spam sending zombie PCs making hundreds/thousands of MX queries in minutes. Until such machines are innoculated, how can BIND be tweaked so such traffic does not compromise legitimate queries?
>   Note that this is just an example and I am open to any suggestions.
>   Thank you -- Chris
> Mark Andrews <Mark_Andrews at> wrote:
>> The Doctor wrote:
>>> Just wondering what methods can be use to stop DoS attcks
>>> such as half-open connection overload on port 53 using named.conf ?
>> Neither BIND nor any purely user-space app can really prevent "half-open 
>> connection overload"s (are you trying to describe SYN flooding?), since 
>> they don't even see the incoming connection until and unless it's fully 
>> established.
>> You'd need something with deeper hooks into the TCP/IP stack, or a 
>> separate device, in order to prevent those.
>> It should be noted that most normal DNS traffic uses UDP not TCP. Unless 
>> you're serving up a lot of huge RRsets that necessitate TCP retries, it 
>> should be fairly easy to set, within your Intrusion Prevention device or 
>> firewall, a reasonable threshold on SYN packets incoming to port 53. You 
>> might want to make exceptions, of course, for slaves that use the 
>> standard AXFR/IXFR-based method for replication of zone data, since that 
>> uses TCP as well (IXFR can use UDP, but will fail over to AXFR under 
>> certain circumstances, that's why I lump them together).
>> - Kevin
> Named will also, by default, use the "dataready" accept
> filter if it is available. There has also been some work
> done on a "dnsready" accept filter. The listen queue length
> is also controllable from named.conf (tcp-listen-queue).
> Mark

More information about the bind-users mailing list