Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Date: Wed May 23 2001 - 15:14:04 CDT
On Wed, May 23, 2001 at 06:58:07PM +0300, Jarno Huuskonen wrote:
> I noticed that you have added a patch for glibc-2.1.3 to use more random
> dns query ids (the same patch you have for bind-4.9.x ?).
Yes. I've adjusted the code such that it is now shared for both the
glibc patch and BIND 4.9.x-OW.
> Have you done any tests to see if the patch adds any performance
> penalties etc. ? (My rough guess would be that any penalties will be very
You're right, there's no noticeable performance impact. Even when
used in BIND (which, unlike a client resolver library, serves multiple
client machines), the performance is still very good:
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
named 103 0.2 22.5 29220 28784 ? S May 12 34:57 /named/named -t /named -u named
This is BIND 4.9.8-OW1, serving about 950 primary zones (including
reverse for a /19) and used as the primary caching nameserver for
client machines in the /19. It produces about 1 GB of DNS traffic
monthly (that leaves our network). The machine is a Pentium II at
350 MHz, and the named takes 0.2% CPU.
> (Also have you tested bind-8.2.3 with 'use-id-pool yes;' to see if it
> uses decent query id's and how it compares to your res_randomid patch ?)
No. I wonder what they're using for the randomness source (I haven't
checked the code, I'm not using it).
> Have you done (or considered) a similar patch for glibc __gen_tempname ?
> Here's part of the __gen_tempname code (looks similar to the res_randomid):
> value += ((uint64_t) tv.tv_usec << 16) ^ tv.tv_sec ^ __getpid ();
Yes. This is on my TODO for our glibc package. There's actually a
worse problem with this code where it doesn't actually add _any_
randomness between the attempts to create a file. But this is at
worst a DoS against a particular libc call.
> (I guess it couldn't hurt if __gen_tempname would accept more than six X's).
Well, OpenBSD programs typically pass 10 X's which aren't fully used
on glibc. So, yes, this could be improved as well, but I don't think
makes that much a difference.
> This probably isn't very interesting but might help some (closed source)
> programs (if you have to use them) that use mktemp/tempnam with or
> without O_EXCL.
Actually, I'm more concerned with the DoS possibility against programs
which correctly use mkstemp(3). This possibility does exist with the
> Have you considered using something like prngd as a random source ?
I don't think there's any need for prngd. If anything is found to be
wrong with our in-kernel randomness pool, that would need to be fixed.
> OpenSSH seems to recommend prngd.
Only for systems which lack /dev/*random.