forwarders are unreachable -> lookup fails?
Kevin Darcy
kcd at daimlerchrysler.com
Thu Mar 22 03:07:46 UTC 2001
Brad, I think we are miscommunicating here. I'm not arguing against local caching;
I'm arguing against -- or at least questioning the rationale of -- forwarding. You
have chosen forwarding because you need -- or at least _think_ you need --
"one-world consistency". Personally, I think the justifications you've given for
that so far amount to problems with your support infrastructure and/or of
over-marketing to your customers the consistency of Internet email delivery. But,
regardless, *given* that you've decided to forward queries to a central cache, I am
totally in agreement with you that local caching is highly desirable to keep that
traffic down to a manageable level.
BTW, Jim and I have discussed these matters in the past, and I think we are
basically of one mind about this. But, of course, he can speak for himself...
- Kevin
Brad Knowles wrote:
> 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