What kind of hardware?
Brad Knowles
brad.knowles at skynet.be
Fri Mar 9 00:33:07 UTC 2001
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
More information about the bind-users
mailing list