This is a discussion on Re: "reasonable" bulk resolver behavior - DNS ; Barry Margolin: > It depends on how powerful and busy the nameserver you're querying is. > If you're running your own nameserver and it doesn't have lots of other > clients, you may be able to go full out; if ...
> It depends on how powerful and busy the nameserver you're querying is.
> If you're running your own nameserver and it doesn't have lots of other
> clients, you may be able to go full out; if you're querying your ISP's
> nameserver, you'll probably have to throttle down quite a bit.
In my particular case, I control the nameserver (it's on localhost), but
I wish to release this as a generic tool, and in order to be responsible
I need to set some kind of default value that the "Joe Users" get (all
five of them, probably) when they install the software without thinking
about it. If I pick too few, it's no better than synchronous resolving.
If too many, then I'm a resource hog.
My inclination is "40 or so".
Paul Vixie wrote:
> altavista routinely ran "manyhosts" with 1000 concurrent threads and five
> recursive nameservers (all of which were just virtual BIND8's on the same
> host, at 127.0.0.2, 127.0.0.3, and so on), and never received complaints.
Well, I think I'm unlikely to hit 1k threads/requests :-)
> for the record, i still think that using a thread-safe resolver like IRS
> (which is contained in bind8 and bind9's "libbind") and pthreads is the
> right way to go, compared to ADNS. though i'd still like to do something
> that ran natively on top of bind8's "eventlib" someday.
Is this out of personal preference, or some deeper technical reason?
I generally avoid pthreads because it's just not portable enough: I can
make singlethreaded select() do nearly anything - for DNS or whatever -
including on Win32 where I have some modest involvement [see "MVP" below].
Paul, Barry: thank you for your input.
Stephen J Friedl | Security Consultant | UNIX Wizard | +1 714 544-6561
www.unixwiz.net | Tustin, Calif. USA | Microsoft MVP | email@example.com