We also return random ordering to DNS requests in an attempt to
spread load.

However, DNS has nothing to do with arisawa's fix.  He is correct.
When an ftp client uses Active mode transfers, it requires the
server to call it back.  If the client is behind a box doing
NAT for it, the data call back may have to be from the same
address that the control call was to.  I say may because the
ftp rfc doesn't require this, so some NAT box may get it right
if it just uses a two tuple (local port/local addr) rather
than a 4 tuple (local port/local addr/remote port/remote addr)
to index its mappings.

I live behind a NAT now, much to my utter shame and horror,
because my ISP stopped giving out multiple addresses.  However,
I don't notice the problem; perhaps because all servers these
days seem to accept Passive ftp connections, i.e., the client
makes both the control and data connections avoiding the call
back scenario arisiwa is fixing.  I take it he still talks to
some old ftp servers.  The code would work in more situations
with his fix, regardless of what the rfc says.  I remember the
original RFC was written to allow the data call back to come
from an entirely different machine to allow load distribution
but since noone does that, I wouldn't expect any NAT to support
it, except by accident.