Date:        Tue,  9 Sep 2003 21:04:09 +0900 (JST)
    From:        itojun@itojun.org (Jun-ichiro itojun Hagino)
    Message-ID:  <20030909120409.BEDDB199D1@starfruit.itojun.org>

  | 	here's randomid(3) code i propose to integrate into libc.

I know this has already been done (it seems that allowing less than
1 day for comments, and getting none, is considered as "all OK, do it"
these days...)

I don't care about the function, or putting it in libc, but ...

  | 	first we'll use this from:
  | 	- lib/libc/net (DNS query ID)

it is absurdly overblown for DNS queries.  The transaction ID in DNS
packets is (from rfc1035)...

ID              A 16 bit identifier assigned by the program that
                generates any kind of query.  This identifier is copied
                the corresponding reply and can be used by the requester
                to match up replies to outstanding queries.

For the purposes of our resolver, using "0" all the time would almost be just
fine I suspect, as it is probably unlikely that there are many concurrent
outstanding queries (this is the libc resolver, as distinct from what
the nameserver does, of course).   Certainly using 0 1 2 3 ... for queries
as they're sent (which would help eliminate ancient replies that arrive
well after the code had given up waiting) is all that is ever needed.

Anyone who believes that setting the ID to a random value, with the
thought in the back of their mind that this is adding "security" by
making it hard to spoof replies is simply deluding themselves.

If that kind of security is needed (which it may easily be) between the
libc stub resolver, and the system that is acting as the back end cache,
then a TSIG setup should be used instead, so the server can genuinely
authenticate its reply, and the resolver can know that the answer has come
from its trusted cache (which still says little about the validity of the
answer unfortunately).

No comment on the use of this new function in the rpc code, I don't know
enough about what's relevant there, but using it for DNS queries is simply
insane.

kre