On Tue, 12 Oct 1999, Greg A. Woods wrote:
> [ On Monday, October 11, 1999 at 21:54:24 (-0700), Pete Naylor wrote: ]
> > Subject: Re: [Exim] Delivery optimization tips for large lists ?
> >
> > That's right - I hope nobody is silly enough to configure their DNS in the
> > manner that you've just described. Really bad practice.
>
> Come on now!!!! That's one of the better ways to configure multiple
> fail-over mail servers! Indeed using multiple MX records is adequate in
> some circumstances too, but using multiple A RRs is most definitely 100%
> *NOT* "bad practice"!
Having multiple MXs, each for a hostname with multiple As is fine. The
example being discussed was using one MX with multiple As, and how nscd's
caching of said silliness caused someone problems.
> In fact if you are a very large entity and you require more than ten or
> so mail servers then using multiple MX RRs, each with multiple A RRs on
> the target host, is the *ONLY* way to achieve the desired result.
No it isn't. One might employ load balancing devices to share a single IP
among any number of mail hosts. Foundry ServerIron switches work great
for me.
> Check
> out compuserve.com, aol.com, uu.net, and any other really big e-mail
> provider who's technical folks do know mostly what they are doing. Even
> some of the ones who don't have everything esle figured out yet, such as
> mail.com, have figured this bit figured out.
No doubt - I've dealt with that situation myself. How many of them have a
single MX? Only uu.net. It refers to two A RRs. Do you know for a fact
that each of those IPs isn't served by some form of network device which
handles fail-over? Do you know for a fact that they don't insert a /32
route into their backbone for each of those IPs and modify that route to
send the traffic to a host at another data center when monitoring detects
a failure (that doesn't appear to be the case - but it's also a
possibility)? What do you know about the manner in which they've deployed
the service? If outward appearance is to be believed, they have two
machines referred to by a single MX, and both machines are likely on the
same segment - they have no off-site backup MX. This would be a pity,
because they'd be missing out on redundancy which is there for the taking.
I've worked for large companies before, and I've seen them make big
mistakes. I don't necessarily assume that uu.net wouldn't do the same.
> The SunOS-5.x (Solaris-2.x) nscd *IS* misconfigured for default
> operation on the Internet.
Interesting claim - but you've provided nothing to back it up.
> I believe Sun even admit this themselves now
> (and for certain many of their more astute technical people realise this
> and will openly say it to be so).
Strange - I've seen a number of Sun engineers defend nscd for Internet
use. Furthermore, I've used it myself with great success. In some cases
I've tweaked the configuration to get the best results for a particular
host, but in general the defaults work fine.
> The *only* proper way to run a
> SunOS-5 box with DNS as the primary information source for host
> information is to either kill nscd, or to tell it not to cache host
> information, and that's done trivially by uncommenting the example line
> in /etc/nscd.conf given for exactly this purpose. Any SunOS-5 box
> running on the Internet as a mail server is most definitely not
> optimally configured until this change is made.
You keep emphasizing this notion, but you have yet to provide any
evidence. The fact that I've used nscd extensively (in both very small
operations and very large) with no ill effect is contradictive to your
views.
> Leaving nscd enabled for caching host information while at the same time
> using BIND for host information causes exactly the kinds of problems
> that any duelling cache protocol implementations will bring. Don't do it!
nscd is a complement to a caching named, and provides benefits which
cannot be realized through a caching named alone. It's a pity that so
many people misunderstand the purpose of nscd, or take the ranting of a
few individuals as truth. Those who use nscd appropriately avail
themselves of some very useful performance gains.
--
/*-------------------------------------------------------------*
* Peter James Naylor ## SysAdmin, Supernal Technologies, Inc. *
*-------------------------------------------------------------*
* pete@??? ## <http://www.supernal.net> *
*------------------------------------------------*/
