[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