forwarders are unreachable -> lookup fails?
Brad Knowles
brad.knowles at skynet.be
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
machine).
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
throughput.
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 skynet.be>
/* efdtt.c Author: Charles M. Hannum <root at ihack.net> */
/* */
/* Thanks to Phil Carmody <fatphil at asdf.org> 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
*2-k%8^8,a=0,c=26;for(s[y]-=16;--c;j*=2)a=a*2^i&1,i=i/2^j&1<<24;for(j=127;++j<n
;c=c>y)c+=y=i^i/8^i>>4^i>>12,i=i>>8^y<<17,a^=a>>14,y=a^a*8^a<<6,a=a>>8^y<<9,k=s
[j],k="7Wo~'G_\216"[k&7]+2^"cr3sfw6v;*k+>/n."[k>>4]*2^k*257/8,s[j]=k^(k&k*2&34)
*6^c+~y;}}
More information about the bind-users
mailing list