BIND 9.3.5-P1 random UDP src ports: some DNS responses delivered to wrong process

Irwin Tillman irwin at princeton.edu
Thu Jul 10 00:57:00 UTC 2008


After upgrading to BIND 9.3.5-P1, I'm seeing some DNS responses
arriving at my host being misdirected to other processes (not named)
running on my host.

It appears to be because when named needs to send a query and chooses
a random UDP source port,
it's able to bind() that port even though the port's already in-use.

--

My platform is Solaris 10 on SPARC.

I have a RADIUS server already bound to IPv4 INADDR_ANY UDP port 1812,
specifying SO_REUSEADDR.

named is running without specifying any 'listen-on'  or 'query-source
address'.
I see that when it sends a query and chooses a random UDP source port
'x'
it binds the socket (which is waiting for the DNS response) to IPv4
INADDR_ANY UDP port 'x',
specifying SO_REUSEADDR.

Sometimes 'x' happens to be 1812.
Solaris 10 allows this second bind() to IPv4 INADDR_ANY UDP port 1812
to succeed;
I assume that's because of the SO_REUSEADDR.

When the DNS response to the query arrives, Solaris may deliver it
to the RADIUS server; I can confirm that because my RADIUS server
logs these packets as malformed in various ways.

(I imagine that the converse may also be true; that some of the
packets sent by RADIUS clients to
the RADIUS server  may instead be delivered to named, but am not
running named at a high enough
logging level to confirm that.)

For a long-running UDP-based server running on a fixed UDP port,
I see I can work around this using named's new 'avoid-v4-udp-ports'
option.
But I imagine that won't solve the problem in general;  there may
be other UDP servers (say RPC-based servers) that pick ephemeral UDP
ports each time they start;
I can't specify those ports in named's 'avoid-v4-udp-ports' option.

Have I missed something here?
(Is it right for BIND to specify SO_REUSEADDR when it binds a socket
it will use for a UDP query with a random UDP source port?)


More information about the bind-users mailing list