Blocking DoS on Bind9

[Paul Vixie]

Barry Margolin <barmar at alum.mit.edu> writes:

> > 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.
> 
> Don't most Unix TCP implementations have SYN-flood protection built into
> them these days.  And I expect most high-end firewalls also do it at the
> border.  So it's not generally something one worries about in the
> application.

accept_filter(9) on freebsd describes a method of delaying a return from
accept() [or even readability of a listener socket in select()] until some
data has been received.  there are two filters shipped with the system, one
is accf_data(9) which waits for "any data" before waking a listener, the
other is accf_http(9) which waits for a valid HTTP transaction before waking
a listener.  the latter is used in apache, and in my own ddos wars i've 
added it to squid (with help from duane wessels), and it makes a HUGE
difference.

> The problem that might have to be dealt with in the application is
> fully-open connection overload.  Suppose a botnet opens thousands of TCP
> connections to port 53, this might fill up the TCP stack's connection
> queue.

that would merely disrupt normal tcp/53 service from the name server, which
is fragile in the best of times due to the TCP connection management
paradigm called for in RFC 1035 (basically, in overload conditions, the
oldest sessions are killed to make room for newer ones).  udp/53 is far more
reliable.  so my concern on DNS DDoS is really about keeping the nameserver
process from being too busy to do real work, and for that, acceptfilter(9)
is almost ideal.  accf_dns(9) would be even better, of course!  and as you
say, DDoS resistance begins with syn flood protection, which all modern OS's
have got.
-- 
Paul Vixie