Multiple DNS implementations vulnerable to cache poisoning

> surely the tool is not focused at a dns operator/admin audience..
I suspect the tool's form might partly be meant to obscure exactly what
patterns it is looking for.
Kind of how one might release a vulnerability checker in binary form
(but with source code intentionally witheld)

5 query samples would not seem to be a sufficient number to compute the
probability that the TXIDs and
source ports are both independent and random, with stringent confidence
intervals, and that there is
no sequence predictability (due to use of a PRNG)...

More exhaustive tool would operate on tcpdump output or run live with
pcap, gather samples of sequences of TXIDs,
port numbers, timestamps.

And perform tests for independency between TXID and port number, timestamp,
and some statistical tests for randomness.

Since it appears as though a significant part of the solution is tied to
upgrading to new code, which implements better PRNG *and* random source
ports, it seems that one indicator for vulnerability is simply the reuse
of a source port number, which should be trivial to identify without any
concern for having to look for "patterns" within the PRNG-generated TXID.

You do not necessarily need to be able to verify that something is NOT
vulnerable in order to detect vulnerability. Your answers will only be
"is vulnerable" and "might be vulnerable" of course, but that's useful
all by itself.

... JG