Actually if transaction IDs are random (which they must be to avoid various already known
exploits) and the server has this sub-optimal behaviour you get a situation similar to the
Sending A identical queries, followed by B purported answers with arbitrary sequential
transaction IDs to the query gives you a much better chance of spoofing the target server than
sending A+B queries and one answer, or one query and A+B answers.
According to a quick back of the envelope calculation, just 128 queries and 128 spoof answers
gives you about 25% chance of success, equivalent to sending many thousands of spoof answers
ordinarily. Doubling the number of packets sent (256 queries and 256 answers) improves this to
more than 60%.
However this can't be the totality of the new discovery (in the sense that it's new at all)
since it supposedly also threatens direct queries which aren't directly instigated by an
attacker and are usually cached, e.g. those from the libc stub resolvers in many operating
I think we have to assume that DNSSEC is the way out of this quagmire and that either we have
to solve the political problems or work around them. That could mean shipping DNS
implementations with a set of keys for the major TLDs and leaving the root unsigned.