[dns-operations] Why non-repeating transaction IDs?

[Florian Weimer]

* Simon Waters:

> On Friday 03 August 2007 08:59, Florian Weimer wrote:
>> I see that people use lots of home-grown algorithms to get random, but
>> mostly non-repeating transaction IDs in their resolvers.  I can't find
>> the rationale for this; a straightforward PRNG or stream cipher seems
>> sufficient for this task.  Any pointers to RFCs or papers are
>> appreciated.
>
> PRNG are not random, and thus too predictable. 

The former is correct, but the latter is not.  If "too predictable"
boils down to "significant advancements in the analysis of one-way
functions such as SHA-x", I can certainly live with that.  This is a
much stronger approach than the current homegrown PRNGs.

The trouble is that verifiable high-entropy sources a very hard to
obtain, especially if you need a non-trivial symbol rate and
reasonably portable implementations.  Cryptographically strong PRNGs
are much easier (after you have obtained the seed).

But I'm not concerned with randomness, but with "non-repeatable
randomness" requirement.  In essence, implementations fix a random
permutation of all possible transaction IDs, use up some portion of
it, and then switch to the permutation.  I don't see the need for this
behavior.

> The same problem pattern has been done to death for TCP sequence numbers. 
> Search for "TCP" "sequence numbers" "vulnerabilities" "strange attractors", 
> and such.

The situation with TCP differs significantly, see appendix A in RFC
1185 for some explanation (to be taken with a grain of salt, there
have been quite a few developments in this area).

DNS over UDP is completely different because late-arriving responses
do not affect previous, successful name resolutions.