What kind of hardware?

[Brad Knowles]

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

>  I think you misunderstood. I'm not denying that mail servers should run local
>  caching nameservers. Obviously they should. I was taking issue only with the
>  *forwarding* part. If every mail server runs an *autonomous* caching server,
>  this would actually alleviate the load on those central caching servers,
>  would it not?

	At the expense of providing consistent answers, and generating 
unnecessary network traffic, and unnecessarily increasing the load on 
the remote nameservers, and unnecessarily delaying mail while you 
wait for serverN+1 to resolve a domain that has already been resolved 
by serverN and is already cached locally on the central caching 
nameservers, yes.

>  Okay, propagation delay, I understand that perfectly. But how many folks run
>  non-NOTIFY-capable nameservers these days, really? These propagation problems
>  should eventually go away, or at least subside to "noise" level.

	How the heck does NOTIFY figure in at all when you're talking 
about caching nameservers and caching forwarding nameservers?!?

>  Hmmm... I thought "the" lesson behind all cache poisoning attacks was "don't
>  implicitly all of the RR's one sees in a DNS response packet". Of course,
>  there could be multiple lessons, but I'm not sure that "consistency over
>  occasional correctness" rates very high on the list, if it's on there at
>  all...

	Indeed, there are multiple lessons that can be learned from the 
cache poisoning attacks, and the need for consistency above 
occasional correctness is certainly a very important one.

>  With all due respect, if one mailbox is getting thousands of complaints a
>  day from a userbase of 20 million people, then a) that's actually not a
>  very high percentage, and b) sounds like an organizational problem --
>  isn't that what low-level tech-support helpdesks largely exist for, i.e.
>  to filter out "routine" (non-)problems so that people with clues can get
>  their work done?

	That was after having complaints being filtered by at least three 
levels below me.  And I was still getting hundreds of complaints a 
day.  Just try to imagine how many thousands or hundreds of thousands 
of complaints were actually being registered each day, in order to 
result in hundreds of these complaints per day filtering down to my 
level.

>  Maybe it's just a difference in userbase and/or requirements. I assume this
>  is some ISP or ISP-like entity serving these 20 million people, where email
>  *is* one of the main reasons, if not *the* reason, for the business
>  relationship between the provider and the end-user in the first place.

	E-mail is the *only* mission-critical application.  If the user 
can't get to the web, or irc, or ftp, or anything else, they'll 
complain but they'll come back.  If they can't get to their e-mail, 
then they are permanently lost.

>  When your main business is something *other* than providing Internet
>  services, however, e.g. building cars, then often it's far more important
>  that the mail *gets*through*, even if it has to be re-sent over and over,
>  than just the *appearance* that everything is working smoothly.

	So long as the user doesn't have to repeatedly re-transmit that 
message, you are correct.  The moment the user has to get involved 
because your system is "screwed up" and doesn't have a consistent 
picture of the world across all machines, you lose.

>                                                                   If an
>  email miscommunication with one of our parts suppliers results in
>  the shipping of the wrong part and ultimately the idling of a production
>  line (at millions of dollars a minute), then it will be little consolation
>  to hear that, despite the fact that a good MX was available in DNS, at
>  least the email servers ignored that MX and failed *consistently*.

	If the orders for parts A & C go through and each cost the 
customer millions of dollars, but the order for part B doesn't go 
through, and the result is that all the money spent on parts A & C is 
wasted, and the entire company goes out of business, then that is 
also small consolation.

	It would be much better for the customer to find out ASAP that 
the order for none of the parts went through, and they need to make 
alternative arrangements in order to get their production line back 
into operation.

>                                                                      We
>  operate on a "get the mail there no matter what" basis, rather than on a
>  "hide the inherent inconsistencies of the Internet from the users so it
>  won't confuse and/or annoy them" basis. I'm not saying one is inherently
>  more "valid" or "legitimate" than the other; just that they are driven by
>  different needs.

	Note that returning inconsistent answers makes it virtually 
impossible to do any successful debugging of the problem.  This 
increases the costs on customer service, on the network operations 
center, on the third-level support personnel, and on the systems 
operations personnel.

	Indeed, consistency is one of the six basic types of security, as 
listed on page 11 of _Practical Unix Security_ by Simson Garfinkel & 
Gene Spafford.  Thanks to another reader of bind-users for pointing 
this out.  ;-)

>  To give you another example of this _modus_operandi_: if the quality of
>  Internet DNS administration keeps dropping like it has been, I may have
>  to even start *restarting* the nameservers periodically on my mail
>  gateways, in order to flush out all the botched NS RRsets that I keep
>  seeing in the cache.

	There's enough garbage out there (fully 25% of all ccTLD zones 
that are carefully checked for consistency still have lame 
delegations, and more than 50% of all zones in .com have lame 
delegations), so I don't think that the use of a centralized set of 
caching nameservers to which all unknown queries are forwarded is 
going to materially impact this issue.

	IMO, all caching nameservers on a busy network should probably 
get reloaded at least once a day, just to clean out the cruft.  It's 
sad, but this appears to be necessary.


	Unfortunately, this problem isn't going to be solved until the 
registries start getting a lot tougher about validating the provided 
information, and periodically re-validating that information and 
cutting off the zones that are no longer compliant.

	Indeed, since they could turn this into a money-making 
proposition (e.g., "fix your problem and pay us $$$, or we cut you 
off"), it would seem that this problem should resolve itself quite 
quickly, as soon as the registries wake up and smell the roses.

>                        That, of course, would be a *terrible* waste of
>  resources -- not only my resources, but those of the TLD servers and of
>  all of the Internet nameservers for the domains with which we communicate.
>  But my mandate is "get the mail through", and to accomplish that, I'll
>  resort to draconian measures like periodic restarts, if necessary...

	You're not using forwarding caching nameservers on your 
individual hosts, so what do you care about the load placed on the 
TLD nameservers?


	If you really cared about the unnecessary load placed on servers 
outside your network, or the unnecessary amounts of traffic generated 
on your own local network, or the unnecessary delays engendered by 
having each and every one of your servers have to go out to the 
outside world to look up all information, then you'd do exactly as I 
recommend.

	Otherwise, I don't think you really have a leg to stand on when 
you talk about generating unnecessary load on the TLD nameservers.

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