Tuning BIND 8

[Brad Knowles]

At 10:26 AM -0700 6/19/01, DD wrote:

>         The boxes are getting hit pretty hard, what kinds of things can I
>  do to ensure speedy resolution? The named.conf is pretty standard, and
>  the resolvers are not authoritative, just caching. solaris 26 OS.
>  (company would like to migrate to solaris 8 soon)
>  Can I play with the cache of a resolver? To what benefit?

	No, the resolver doesn't have a cache.  Only the server.

>  Are there any lesser known options for named.conf that could improve
>  performance?

	Not that I know of, no.

>  Does anyone here use a "server farm"? How sucessful? What platform?

	I set one up when I was working at AOL, with four DEC Alpha 4100s 
with four EV5 processors, 4GB of RAM, and four copies of BIND 8 
running on each machine (each bound to a particular virtual IP 
address on the FDDI interface), and ran DECSafe ASE to cross 
fail-over the applications.

	We matrixed these across the client systems, and benchmarks 
indicated that each instance of BIND should be capable of handling on 
the order of at least 2000 queries per second (I couldn't manage to 
push it any harder than that, so we don't know for sure what the top 
end was), for a total of at least 32,000 DNS queries per second 
across the farm.


	However, if I had to do it over, I would now use BIND 9, which 
has built-in multi-threading, and we wouldn't need four separate 
copies of BIND per machine.


	Search the archives for the names "Rick Jones" and "Matt 
Simerson".  Rick has some very interesting papers he's written for 
HP, showing how they've gotten a single instance of BIND to scale up 
to 12,000 DNS queries per second (answered authoritatively, not from 
cache), on some specific high-end configurations.  Contrariwise, Matt 
has posted here some preliminary results of work that he's done in 
benchmarking caching-only nameserver configurations on lower-end 
hardware (but still getting significant numbers).


	On your system, I believe that you really do want to upgrade to 
at least Solaris 7, to benefit from significant improvements in the 
networking library.

	You could also potentially set up a two-tiered system where the 
"main" servers answer queries out of their cache, but forward unknown 
questions to a central server (or set of servers), to take advantage 
of a second-level cache.  However, forwarding in this manner usually 
makes the system less robust, more subject to unexpected failure, and 
less scalable (see pages 333-335 of Chapter 11 of 4th edition of _DNS 
and BIND_ by Paul Albitz and Cricket Liu, published by O'Reilly & 
Assoc.).  So, you want to be really careful when looking at this sort 
of thing.

	One of the best ways to build a highly scalable nameserver 
infrastructure is to implement a caching-only nameserver on each 
machine that requires nameservice, and de-centralize all that work 
for servers inside your network.  Of course, this may cause issues 
with the firewall, and may cause some machines to have a slightly 
different view of the world than others (which might cause some mail 
messages to bounce when they are directed through one set of 
machines, and to be successfully transmitted when directed through a 
different set).  You'll have to weigh the costs and benefits of doing 
this sort of thing, and make up your own mind.
-- 
Brad Knowles, <brad.knowles at skynet.be>

/*        efdtt.c  Author:  Charles M. Hannum <root at ihack.net>          */
/*       Represented as 1045 digit prime number by Phil Carmody         */
/*     Prime as DNS cname chain by Roy Arends and Walter Belgers        */
/*                                                                      */
/*     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob        */
/*   where title-key = "153 2 8 105 225" or other similar 5-byte key    */

dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'