Random source port isn't random?

[Jim Reid]

>>>>> "Ian" == Ian Northeast <ian at house-from-hell.demon.co.uk> writes:

    Ian> What I find is that when named is started from an
    Ian> initialisation script at boot time it always uses port
    Ian> 32768. This is at the bottom of the ephemeral range in the
    Ian> default SuSE configuration.

    Ian> So how does bind pick this "random" port number? 

It doesn't. The kernel chooses. It does this at random based on the
state of kernel data structures at the time a bind() system call is
made and no explicit port number was specified. Since these kernel
data structures are likely to be in a known state at boot time, it
shouldn't be a surprise that a "randomly selected" port number at that
point turns out to be deterministic.

    Ian> I would like this number to be truly random. In particular I
    Ian> need my two caching servers serving my mail exchanges to use
    Ian> different ones. I know I could do this by specifying it
    Ian> explicitly, differently, in the two but this could break if
    Ian> by some chance the ports I specified happened to be in use. I
    Ian> would like it to behave as documented.

These are mutually exclusive goals. If the port numbers are truly
random, then at some point both servers will use the same one. Why do
you think you need to care about which port number your name servers
will randomly use for the queries they make? It simply does not matter.
What makes you think your name servers have to have different port
numbers?

    Ian> This has come to light because of a misconfigured third party
    Ian> firewall which is blocking UDP packets on source port 32768
    Ian> (or possibly the responses back to me). The admin's
    Ian> explanation was that he needed to do this to protect his
    Ian> rpc.statd which listens on this port. I have attempted to
    Ian> point out that he has this backwards but I suspect I will not
    Ian> get anywhere.

So leave them to fester in their own self-imposed mess. They have a
serious lack of clue. First of all, DNS queries can come from any port
number. Filtering DNS traffic based on some fantasy that the queries
only come from a specific port number is just wrong. Secondly, this
administrator doesn't understand how RPC services work. They can't
assume rpc.statd always and only runs on port 32768. [This could well
be another example of a deterministic choice of port number at boot
time.] That port number is on their server BTW, not yours! So
preventing traffic from the internet which uses that source port
number makes no sense at all. Even if their firewall blocks traffic TO
this port number on their server, that's no excuse for blocking
inbound traffic FROM this port number to port 53 on their name
servers. Or outbound traffic from their name server to this port
number anywhere on the internet.