What kind of hardware?

Brad Knowles brad.knowles at skynet.be
Thu Mar 8 21:30:35 UTC 2001


At 2:44 PM -0500 3/8/01, Kevin Darcy wrote:

>  As some of you may know, I have a low opinion of forwarding. In my view,
>  it's a necessary evil in some situations to get around connectivity
>  problems, e.g. firewall boundaries, and in *some* network/DNS
>  architectures conveys performance benefits *some* of the time, but an
>  evil nonetheless and something generally to be avoided. So I'm
>  naturally biased against your "preferred" setup to begin with.

	On the networks on which I've set this stuff up, the central 
caching nameservers were already doing multiple hundreds or tens of 
thousands of DNS queries per second, and without the caching 
forwarding servers running locally on each machine performing a major 
service, the central caching nameservers would get pummeled into the 
ground.  On busy networks, I simply don't see any other alternative.

>  Having disclosed that, I have to wonder, why would a non-forwarding
>  caching server get *inconsistent* results?

	Well, if you have a case where some authoritative servers haven't 
picked up the latest changes, and one local caching nameserver 
decides to ask a particular question of one authoritative server, and 
another local caching nameserver decides to ask the same question of 
a different authoritative server, they could obviously get totally 
different answers.

	Think back to all the zones you've heard discussed on this 
mailing list where at least one of the authoritative servers had a 
different SOA serial number than the others.

>                                              You mean, because the
>  administrators of the target domain screw something up, so that some
>  authoritative servers for their domain give out different data than
>  the others?

	Yup.  See above.

>               Frankly, I don't see this as my problem to fix (or work
>  around); it's *their* problem to fix.

	Actually, this is a problem that is inherent in the nature of the 
way the DNS works, since secondaries can always be more or less 
out-of-sync with the primaries, and records for mail (or other 
services) could well be different between those different copies of 
the zone(s).

>                                                                I mean,
>  what if somebody's slave DNS server is temporarily hacked, with the
>  hacker attempting to intercept the domain's mail? If you happen to
>  cache the malicious MX record, now suddenly *all* of the mail destined
>  from your servers to that domain is going into the bad guy's mailbox,
>  perhaps long after the intrusion is detected and the genuine MX record
>  restored (obviously if the bad guy is any good, he'll set a high TTL
>  value on the malicious record to maximize the effect of the hijacking).

	Consistency is more important than occasionally getting the 
correct answer.  This is the lesson behind all cache poisoning 
attacks.

	Try being the Internet mail systems administrator for twenty 
million people, and literally getting hundreds or thousands of 
complaints *PER DAY* in your private mailbox, where Customer A is 
complaining that they sent three different messages to Recipient B, 
and only the first and third messages were delivered, because the 
second one was routed through a different machine which had a 
different view of the Internet.

	I'll say it again -- consistency in always giving the same answer 
is more important than occasionally getting the "right" answer.

--
Brad Knowles, <brad.knowles at skynet.be>

#!/usr/bin/perl -w
# 531-byte qrpff-fast, Keith Winstein and Marc Horowitz <sipb-iap-dvd at mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
# Usage:
# qrpff 153 2 8 105 225 /mnt/dvd/VOB_FILE_NAME | extract_mpeg2 | mpeg2_dec -
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=(
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72, at z=(64,72,$a^=12*($_%16
-2?0:$m&17)),$b^=$_%64?12:0, at z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h
=5;$_=unxb24,join"", at b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^$d>>4^
$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^
(($h>>=8)+=$f+(~$g&$t))for at a[128..$#a]}print+x"C*", at a}';s/x/pack+/g;eval


More information about the bind-users mailing list