Date: Thu, 24 May 2001 00:14:04 +0400 From: solar@...nwall.com To: owl-users@...ts.openwall.com Subject: Re: glibc resolver dns query ids 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.