[rbldnsd] bind()-related bug in rbldnsd

Michael Tokarev mjt at corpit.ru
Wed Nov 28 22:44:39 MSK 2007


Anders Henke wrote:
[]
> If rbldnsd is told to bind to 0.0.0.0 and receives a packet for
> 172.19.58.6, the answer is sent with 172.19.59.11 as being
> the originating address. I see this as a bug.

That's why -b option is mandatory now.  It used to bind to 0.0.0.0
by default, but for UDP it's unreliable - exactly because of the
reason you outlined.  What I forgot to enforce is explicit binding
to 0.0.0.0 - the bug is that rbldnsd does not enforce non-zero
argument for -b option.

With UDP, it's impossible to determine local address to which a
packet has been sent - at least not in a portable and fast way.
There's some "black magic" possible with recvmsg() system call
and parsing cmsg structures - at least on some systems.

This is also a reason why BIND for example periodically rescans
a list of local interfaces/addresses and binds to each of them
individually (option named "interface-interval" or something like
that).  BIND contains alot of code around this whole thing, --
I see it as unnecessary baggage.  Rbldnsd is not a general-purpose
recursive resolver that listens on all possible IP addresses,
it should ONLY listen on specific address (better to only one).

> Workaround: when clearly binding to each IP
> ("-b 127.0.0.1 -b 172.19.59.11 -b 172.19.58.6", 
> rbldnsd answers with the IP address where the query has been received.

That's not a workaround, it's THE only proper way to bind to
multiple addresses.

/mjt


More information about the rbldnsd mailing list