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