Bind 9.1.3 stop resolving but is still running.

[Nate Campi]

On Fri, Sep 07, 2001 at 12:07:29AM +0200, Brad Knowles wrote:
> 
> At 11:24 AM -0700 9/5/01, Nate Campi wrote:
> 
> >  I also wonder if part of the poor performance in BIND 9 (when it is
> >  actually answering queries) is due to the three tries against remote
> >  nameservers to see if they handle EDNS0. Can this be turned off?
> 
> 	I've been thinking about this some more, and I recall that the 
> EDNS0 probes are done on a one-time-only/per-nameserver basis, and 
> the results are cached for the life of the named process (i.e., the 
> probes won't be sent again until BIND is restarted).
> 
> 	I'd be very interested to know what your testing results might 
> be, if you were to follow a regime more similar to what Matt Simerson 
> was doing, so that you do a full test run with a clean cache, then 
> repeat the test run again with a primed cache, and do this sequence 
> several times in sequence, in order to try to average out individual 
> ideosyncracies.

The problem was that I always purged my cache for "clean" tests on
recursion performance. I'll do the tests as you have asked. I'll
eventually post results from my tests on a web page, since it gets way
too big for posts here. I may not have anything ready for posting for
quite a while, though.

I do have results from running against cached results, too, but I didn't
really need them. The task I'm stuck with is giving max performance for
an app that resolves IPs into hostnames for our reporting team (parsing
web logs, running reports on logs, etc). Caching performance is relevant
for in-addr.arpa delegations, but not much else in this case. The same
IPs are guaranteed (by the app author) to never get requested twice.

> 	Search the archives of this list for more posts by Matt, and also 
> take a look at the testing methodology used by Rick Jones in his 
> various papers at <ftp://ftp.cup.hp.com/dist/networking/briefs/>.

I've done both. Matt did a hell of a job on his tests, and mine aren't
quite as formal. I'm afraid that I don't have time to setup a test
environment quite like his (despite running all the DNS for my company,
it's a "collateral duty", as I would have called it while in the
service).

> >  Is BIND 9 even up the the task of replacing BIND 8 on heavily loaded
> >  boxes? From my tests so far, it cannot replace our current public DNS
> >  servers, or even caching servers for internal use - due to poor
> >  performance.
> 
> 	Rick has tested only the authoritative performance of BIND 9, but 
> I believe that his tests have clearly shown that, on the right 
> hardware, it can handle at least 12,000 DNS queries per second in 
> that mode, and I have to believe that it can also handle on roughly 
> the same order of queries per second for caching (barring any 
> Internet latency issues).

Agreed on the authoritative info benchmarks. BIND 9.1.3 does about 7000
queries/sec (non-threaded) on a Linux box of mine when queried from the
localhost, but around 2000 queries/sec from a host on the same network
segment (100 mbit full-duplex BTW, on both hosts). From across the
network (same BIND host and same querying host) BIND 8 handles 3100
queries/sec. 

All these results are from queryperf running on Solaris 8 x86. I have a
whole mess of test results from BIND 8 and 9 running on Linux x86, and
Solaris 8 (both x86 and sparc), as well as dnscache. I'll make sure to
post it for review, and will invite instructions on how to better run my
tests.

> 	There is no question in my mind that a properly configured 
> nameserver machine running a properly compiled (with the vendor 
> compiler) and installed BIND 9 is more than suitable for most any 
> nameserver task you may throw at it.

I trust you Brad, I see your name as a proof-reader for Cricket's book
;) Thanks to you, Cricket and Paul, my duties as a DNS admin are much
easier.
-- 
Nate Campi, UNIX Ops WiReD SF, Terra Lycos DNS, (415) 276-8678