[dns-operations] Why non-repeating transaction IDs?
fw at deneb.enyo.de
Fri Aug 3 09:47:54 UTC 2007
* 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
> 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
> 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.
More information about the dns-operations