[conspire] DNS vulnerability details

[Rick Moen]

Quoting Ruben Safir (ruben at mrbrklyn.com):

> With due respect, I fail to see how random outgoing ports will provide
> more security,

Because the man-in-the-middle attacker, posing as the queried
recursive-resolver nameserver, has to send a forged response back not
_merely_ with the correct QID (transaction ID), but also delivered on the
correct port.  If the delivery port for responses, the one used to
originate the query, is always 53/UDP, then it's much easier to forge
a credible fake response -- 2^16 QID value possibilites, rather than
those permutations _plus_ 2^16 possible ports.  ~32 bits of variability
is better than 16, when you're trying to reject forged data.

> The server is still listening on a single know port and send responses
> from a random port (one that is hopefully not being used for vnc) but
> to connect to a known client port.

The _queried_ server is not the problem.  The problem resides with the
recursive-resolver nameserver that's doing the asking:  It's far too 
easy for an imposter to send it credibly faked responses -- that, in
turn, can be used to poison the querying nameserver machine's cache.

That is why the problematic scenario is a recursive-resolver nameserver
that sends _its_ recursive-resolver requests always on UDP port 53, that
_also_ caches received data.  (It also explains why processes that send
out recursive queries but don't cache the results -- libc's "stub"
resolver and most "firewall" appliances' nameservers being obvious
examples -- aren't a problem:  You can send them poisoned information,
but that information won't persist.)