[4275] in linux-net channel archive
Re: SYN floods
daemon@ATHENA.MIT.EDU (Olaf Titz)
Tue Sep 3 16:05:52 1996
Cc: recipient.list.not.shown:;@vger.rutgers.edu
From: Olaf Titz <olaf@bigred.inka.de>
Date: 03 Sep 1996 11:27:42 +0200
To: ;@unlisted-recipients (no To-header on input)
Speed Racer <shagboy@dns.bluesky.net> wrote:
> I think a better idea is to try a "quick" DNS reversal (allow, say, 15-30
> seconds) and drop the connects that can't be reversed. This might be a
> little better than simply dropping the oldest, which could easily be valid
> (maybe even connected over a fast link, if timed right). Of course, you
> could probably make this configurable too.
Two more fundamental problems with this:
1. DNS speed depends on way too many factors that such a short
timeout is more than Monte Carlo testing ;-) Just imagine a situation
where your main DNS forwards a request, can't get it through and your
backup DNS is a slave which also has to forward, etc. There is no
universal timeout, but BINDs resolver library uses 5, 10, 20, 40
seconds - just add that up... OTOH, if your main DNS is 127.0.0.1 and
the request happens to be cached, it returns immediately. A few
seconds later the cache may be expired.
2. DNS is a user level protocol. You definitely don't want to build
the whole DNS baggage into the kernel. This would mean that some sort
of user-land daemon would be responsible for dropping bogus requests.
But one fundamental flaw with the socket API is that you can't refuse
a connection or even do getpeername() before accept() - a problem that
is known since the invention of tcp_wrapper which could be much more
efficient and less confusing if it just were possible to close a
particular connection request from user level.
Of course, the second problem calls for a solution via kerneld. But
given the unreliability of DNS (*), I'm not convinced that this is
desirable. Better just limit the timeout of incoming connections to
something short and make this sysctl-settable.
(*) Yes, it does work well, but not for timing-critical applications.
(Another note on SYN timeouts: First, for outgoing connections this
should be configurable too. 13 minutes is much too much for most
applications. I remember a particular application (Taylor UUCP) where
I had to put an alarm(120) before the connect() just that it doesn't
get stuck. It may be useful for applications involving dialup
connections, however. But this doesn't hold for _incoming_ SYNs, where
the basic IP connection already exists when the first SYN comes in, so
here a much smaller timeout should suffice.)
olaf
--
___ Olaf.Titz@inka.de or @{stud,informatik}.uni-karlsruhe.de ____
__ o <URL:http://www.inka.de/~bigred/> <IRC:praetorius>
__/<_ >> Just as long as the wheels keep on turning round
_)>(_)______________ I will live for the groove 'til the sun goes down << ____
