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
> minimal).

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
current glibc.

> 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.

-- 
/sd

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]