Why forwarding is a Bad Thing

[Brad Knowles]

At 7:00 PM +0000 3/22/01, Jim Reid wrote:

>  In BIND8.2.3 and BIND9, yes. Modulo the usual RTT smoothing in case a
>  faster emerges.

	Blech.  I was not aware of this.  ;-(

>  And one central cache beaten on by everything else in the world is a
>  wonderful place to spread that infection.

	At the very least, it allows you to throw the dice less often, 
and risk getting your cache poisoned.

>  True, but that's only part of the story. You should have added "and
>  get your servers to only query authoritative name servers if at all
>  possible".

	One recursive caching-only name server that gets poisoned is not 
necessarily any better or worse than any other, and so long as it 
only ever hands out that answer non-authoritatively, the problem 
should be relatively minimized.  You can then focus on trying to make 
your central caching servers as secure as possible from getting 
poisoned, and everyone will benefit as a result.

>  You don't. I meant only query authoritative name servers that are
>  found by following NS records. Why forward a query to another name
>  server for resolution when the forwarding server is perfectly capable
>  of resolving the query for itself? Put more simply: what's the point
>  of having a dog and barking yourself?

	I'll refer you back to my newspaper analogy and checking with the 
neighbors before running out to get another copy yourself, quite 
possibly unnecessarily.

>      Brad> 	Right, but if you have a large farm of machines and a
>      Brad> caching name server running on each of them, simply because
>      Brad> of asking similar questions at different times, each of them
>      Brad> is guaranteed to build up a slightly different picture of
>      Brad> the world than each of the others.
>
>  Fine. That's how it should be, shouldn't it?

	Nope.  Not according to the customers I've had.  They saw what we 
were providing to them as one big unitary "system", and the absolute 
worst possible thing you could do to them was to give them 
inconsistent answers to the same question.


	Haven't you ever been royally pissed-off when you've got your car 
in for repair, and you call up to find out what the status is and how 
much it's going to cost you, and you get a different answer from each 
person you talk to?

	Even if this sort of thing happens relatively rarely, the cost of 
small numbers of times that this happens is *way* out of proportion 
to the cost to doing everything you can to make sure that your 
architecture does everything possible to prevent this from happening 
in the first place.


	Or haven't you ever been in a company whose stock was a DJIA 
component, and where you managed situations by the probability of 
something getting put into the Wall Street Journal the next day, and 
worse yet, above the fold?

	Or maybe you haven't ever gotten direct threats of personal 
bodily harm as a result of things that have happened on the systems 
you're responsible for managing?

>  Fair enough, but this still doesn't convince me. Why not run a caching
>  only name server on each mail server and leave them to get on with it?

	See above.

>  Why should anyone care if the cache on server foo is different from
>  the one on server bar?

	When they make threats of personal bodily harm because of this 
precise situation, does it really matter what their motivation is?

>                         I just don't understand why you'd want or need
>  to have identical caches on these two systems: it's not as if the
>  names being looked up by foo and bar are identical after all.

	If all these queries pass through the same central caching name 
server farm, then they actually should be identical, and get 
identical answers.

--
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;}}