Date: Sat, 15 Sep 2001 11:06:46 -0500 From: Bob Martin <bob@buckhorn.net> To: Len Conrad <LConrad@Go2France.com> Cc: Freebsd-isp@freebsd.org Subject: Re: Mail Server - Round Robin Load Distribution Message-ID: <3BA37C96.678DB083@buckhorn.net> References: <5.1.0.14.0.20010915091315.0a697b28@mail.Go2France.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Len Conrad wrote:
>
> >Multiple A records for a single MX, as well as CNAMES for the MX record
> >won't do what you want, as clients and servers (DNS) tend to cache
> >addresses.
>
> BIND caches, of course. The only other non-recursive resolver that Iīve
> heard of is in W2K, MS anticipating that in their primary target market of
> AD + DHCP + DDNS intranets that they needed to reduce query loads. What
> are the others?
>
Internet Explorer > V4.x, Outlook and Outlook Express > V4.x, Netscape >
V4.x (On your Unix box, with netscape running, do a ps -ax... that dns
helper is a caching resolver) Once any of these find a working name==ip,
they will continue to use it until the pair fails.
> >Since your DNS server will always pass along the first A
> >record
>
> false. eg, with BIND, the default RRset-order value is cyclic.
>
> do
>
> dig aol.com mx
>
> 10 times to confirm.
>
> >, or the first CNAME, no balancing will occure.
>
> false. BINDīs RRset-order cyclic or random will cause effective load
> distribution among members of the RRset for resolvers that work strictly
> with the physical order of RRset records.
>
> IN conrast, BIND's own recursive resolver uses RTT, round trip time, to
> determine, continuously and dynamically, which member of the RRset it will
> query.
>
I was being overly simplistic. But using multiple RR's won't load
balance, it causes [hopefully] load sharing, assuming nothing between
the client and the authoritative server caches the response from the
authoritative server. More to the point of this thread, and using your
example, all of aol's mail servers have separate names, and A records,
but have the same MX priority. And on high traffic networks, DNS based
load sharing won't work for a number of reasons, but primarily because
of client caching, and that this method of load distribution doesn't
take server responsiveness into account. For clarity on that last point,
I'll use the example of 2 mail servers with MX records of equal
preference. Each will handle every other request. But if every other
request is a list, one server is going to end up doing a lot more work
than the other, possibly to the point of failure. While this tends to
affect web servers more than mail servers, it's still the reason they
build load balancers. There is also a problem with the authoritative
name servers and timing. If I dig at aol.com 10 times in a row, I will
get cyclic answers. But if I dig at aol.com once an hour for 10 hours
(which is far more likely in the real world) I'm apt to get a much
higher incidence of the same response. Again, this is a much bigger
problem on a high volume network.
> >The priority flag for the MX record was designed for just this reason.
>
> false. the preference field is not for distributing load, but for
> providing backup MX's.
Strictly speaking, it's there to set a preference. Equal preference for
load sharing, and unequal preference for providing backup servers.
(Fault tolerance) We can rest secure in the fact that if this wasn't
the case, the RFC's would have precluded using preference numbers of
equal value.
>
> >domain.com. IN MX 10 mail1
> >domain.com. IN MX 10 mail2
> >mail1 IN A 1.2.3.4
> >mail2 IN A 1.2.3.5
>
> ok, your answer is right, for the wrong reasons. :))
A different way of arriving at the same conclusion perhaps?
Some place in the midst of this discussion, somebody ought to point out
that no matter what you do, using CNAME's for mail servers is a bad
idea. Pick the MTA of your choice, go to their web site, and you are
bound to find something about CNAME loops in the FAQ.
Bob
--
But in our enthusiasm, we could not resist a radical overhaul of the
system, in which all of its major weaknesses have been exposed,
analyzed, and replaced with new weaknesses.
-- Bruce Leverett, "Register Allocation in Optimizing Compilers"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BA37C96.678DB083>