forwarders are unreachable -> lookup fails?

Brad Knowles brad.knowles at
Thu Mar 22 01:11:30 UTC 2001

At 7:20 PM -0500 3/21/01, Kevin Darcy wrote:

>  As we discussed last week, the "one-world consistency" justification is quite
>  debatable, at least in the context of SMTP.

	And as I explained (repeatedly) last week, users get really, 
really, really pissed off when they send three messages and the first 
and last go through fine but the second one bounces simply because it 
was routed through a different machine which has a different view of 
the world.

	I'm not interested in hearing your views (yet once again) on this 
subject, I want to hear what Jim has to say on the matter.

>  As for the performance argument for centralized caching, I still 
>don't see how
>  concentrating a ton of name-resolution work on just a relatively-small set of
>  servers, and introducing extra forwarding overhead in the process, 
>is going to
>  produce any net performance gains, versus spreading the workload 
>over a larger
>  number of autonomously-resolving machines.

	Okay, so you've got a set of centralized caching servers -- four 
DECompaq Alpha 4100s, each with 4GB of RAM, four high-speed 
processors, one copy of BIND running on each processor (this is 
before the BINDv9 days where the program itself is multi-threaded), 
etc....  This farm of centralized caching nameservers can 
theoretically handle about 32,000 DNS queries per second (2000 per 
copy of BIND times four machines times four copies of BIND per 

	This farm is also already handling tens of thousands of DNS 
queries per second, just from the forwarded queries that it is 
getting from the machines which have their own local cache.  However, 
only 1-10% of the total number of queries across the entire network 
is being seen by the central farm of nameservers, because the other 
90-99% is being handled locally out of the cache on each machine.

	Now, imagine what happens if you don't have the local caching 
going on at each machine -- suddenly your centralized farm of caching 
nameservers has to handle ten to a hundred times more queries per 
second than it is already seeing, and yet it's already getting a 
significant fraction (maybe half?) of it's total theoretical maximum 

	Do you really want to have to have forty to four hundred DECompaq 
Alpha 4100s that are configured this way, just to handle the 
centralized nameserving demands for the entire network?  Do you 
actually want to pay all that much money for ten to a hundreds times 
more LAN traffic than is necessary, just for DNS resolution?

	Do the math.  Try using a set of central caching nameservers 
which are used as forwarders by local caching nameservers running on 
each client machine.  Try turning off your "L2 DNS cache" if you 
already have one, or conversely try setting up an "L2 DNS cache" if 
you don't have one.  Actually do this sort of thing in the real 
world, calculate all the statistics, and demonstrate to us your 
real-world experiences on the subject.

	Then please be quiet while we wait to hear what Jim has to say on 
the subject.

Brad Knowles, <brad.knowles at>

/*     efdtt.c     Author:  Charles M. Hannum <root at>             */
/*                                                                         */
/*     Thanks to Phil Carmody <fatphil at> for additional tweaks.    */
/*                                                                         */
/*     Length:  434 bytes (excluding unnecessary newlines)                 */
/*                                                                         */
/*     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob           */
/*     where title-key = "153 2 8 105 225" or other similar 5-byte key     */

#define m(i)(x[i]^s[i+84])<<
unsigned char x[5],y,s[2048];main(n){for(read(0,x,5);read(0,s,n=2048);write(1,s
,n))if(s[y=s[13]%8+20]/16%4==1){int i=m(1)17^256+m(0)8,k=m(2)0,j=m(4)17^m(3)9^k

More information about the bind-users mailing list