At Mon, 01 Sep 2008 00:50:07 +0000,
Jefferson Ogata wrote:

> >> I don't see why you need SO_REUSEADDR. Why not simply leave the UDP port
> >> unconnected and use sendto in the first place?

> >
> > Because you really want to have the kernel do the initial
> > filtering of responses. You don't want your recursive
> > server seeing every stray UDP packet being sent to you.
> > With the amount of malware out there that is trying to get
> > in over UDP your recursive server will be getting lots of
> > noise if you randomly choose such a port. Connected sockets
> > don't interfere with other uses of UDP (e.g. traceroute).
> > You can't probe to see what ports are in use by the recursive
> > server without making the server actually make queries to
> > you.

>
> I see. That clarifies it. So, since you're writing from ISC, does BIND
> do this, or is it on the roadmap if not?


If "this" means connecting UDP query sockets, the latest beta versions
of BIND9 (e.g., BIND 9.4.3b2) do that. These versions also set the
SO_REUSEADDR option so that the same port can be simultaneously chosen
for different sockets as long as the destinations are different. This
implementation choice is actually based on the concern you mentioned:
possibly reduced entropy when we completely prohibit the simultaneous
use of the same port number. (For that matter it also allows to reuse
the same QID for different queries for the same reason).

In practice, however, this doesn't matter much in this context anyway,
since by default the server doesn't open more than 4096 sockets.
Naively limiting the max number of open sockets is subject to a
trivial DoS as you mentioned, so this implementation also introduces a
notion of quota on the number of open queries: if the number exceeds
the quota, the already queries will be aborted (and the associated
sockets will be closed) so that new queries are reasonably accepted.

Using non-connected sockets and allowing it to be reused for multiple
queries are another option, again, as you indicated. If I understand
the code correctly, unbound takes this approach.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: