DNS performance testing - FreeBSD & Solaris - BIND & djbdns

Brad Knowles brad.knowles at skynet.be
Fri Jun 22 17:55:35 UTC 2001


At 11:08 AM -0600 6/22/01, Matt Simerson wrote:

>  We started testing with 8.2.3 and changed over to 8.2.4 when it became
>  released. All the published numbers are from 8.2.4 and 9.1.2-REL.

	I'd like to see this level of detail become a standard part of 
future versions/updates to this report.  ;-)

>  I wouldn't mind seeing them too by my test servers are gone. We weren't even
>  considering BIND 9.2 as a platform to roll out into production so there
>  wasn't much point in testing it. The numbers could be interesting through.

	The numbers would be very interesting for me to see, in 
particular since there has been working done in BIND 9 to avoid some 
of the malloc() bottlenecking problems that were previously 
identified by Rick Jones.  I wouldn't be too surprised to find that 
BIND 9.2 was actually released by the time you were ready to push 
something into actual production (although you may not yet feel 
comfortable with using it in production).

>  That's because they weren't there. I can't say why but when I installed a
>  default BIND 9.1.2-REL on the Solaris machine it broke BIND 8 to the point
>  where it wouldn't answer queries. Our sysadmins customize Solaris enough
>  that things weren't where I expected and I don't know Solaris well enough. I
>  just turned it back over to them and had them install BIND 8.2.4 and I
>  tested against that.

	I can't imagine that installing BIND 9 should actually cause such 
serious problems for Solaris.  IIRC, Solaris is one of the primary 
development/testing platforms for BIND 9, so there must have been 
some other problems or mis-configuration that kept it from working 
correctly.

>  BIND reads zones files from disk into it's cache and serves them from there.
>  Authoritative requests on BIND are the same as cached requests.

	I'd still be interested in seeing an explicit BIND authoritative 
test.  Even if the numbers do turn out to be exactly the same, I'd be 
interested to know things like how long it takes to load zones of 
certain sizes, etc....

	This would also help show up any differences between BIND 8 and 
BIND 9 as authoritative servers.

>  I do that to populate the cache.

	I understand, but I believe that there are better ways to 
populate the cache, and which avoid any potential issues with 
forwarding.

>  With dnscache that's implicit when we configured it to forward the requests
>  for 216.in-addr.arpa so it wasn't an issue but we ended up having to do that
>  with BIND.

	No, you're misunderstanding.  I believe that forwarding should be 
completely avoided.  Period.

	I keep saying "set up the caching nameserver to also be 
authoritative and delegate the child zone to be queried" and you keep 
saying "forwarding".  The two statements are mutually exclusive.

>              While watching the queries with snoop we were seeing BIND query
>  the root name servers upon every query of an IP within the in-addr.arpa
>  space. That was particularly bad behavior.

	Yes, indeed.  That would be particularly bad behaviour.  Were you 
seeing this with both BIND 8.2.4-REL and 9.1.2-REL, or just one of 
them and not the other?

-- 
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,$_)}'


More information about the bind-users mailing list