Date: Sun, 16 Sep 2001 19:03:01 +0200 (CEST) From: =?iso-8859-1?q?Fabrizio=20Ravazzini?= <freefabri@yahoo.it> To: Bob Martin <bob@buckhorn.net> Cc: freebsd-isp@freebsd.org Subject: Re: Mail Server - Round Robin Load Distribution Message-ID: <20010916170301.66091.qmail@web20106.mail.yahoo.com> In-Reply-To: <3BA3A4C1.C344A6F@buckhorn.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, so I understood that the right records are:
domain.com IN MX 10 mail1.domain.com
domain.com IN MX 10 mail2.domain.com
mail1.domain.com IN A 1.2.3.4
mail2.domain.com IN A 1.2.3.5
but do I have load distribution whatever version of
Bind installed in the nameserver?
bye and thanks.
--- Bob Martin <bob@buckhorn.net> ha scritto: > Len
Conrad wrote:
> >
> > >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.
> >
> > hmm. ok, application-level caching.
> >
> > The corporate DNS admin who was desiging to roll
> out W2K and AD to 60K
> > desktops made the point of W2K "resolver" doing
> caching.
> >
> > >I was being overly simplistic. But using multiple
> RR's won't load
> > >balance, it causes [hopefully] load sharing
> >
> > yes, if "balancing" implies load detection.
> Alternating RR physical
> > sequence is dumb load sharing, load distribution.
> >
> > >, assuming nothing between
> > >the client and the authoritative server caches
> the response from the
> > >authoritative server.
> >
> > a caching BIND DNS will also respect its RRorder
> param.
> >
> > > 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,
> >
> > it will and does work
> >
> > > and that this method of load distribution
> doesn't
> > >take server responsiveness into account.
> >
> > yep, it´s dumb, but it´s a lot better than no load
> sharing.
> Unless one of the servers in the round robin goes
> down.
>
> > > 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
> >
> > what´s a query for a "list" ?
> Think MTA, not DNS. List as in email list, like
> FreeBSD-ISP.
> >
> > >, one server is going to end up doing a lot more
> work
> > >than the other, possibly to the point of failure.
> >
> > what?
> See chapter 10 of the 3rd addition of DNS and Bind,
> and FAQ.2of2
> question 5.13 (From ICS)
>
> >
> > > While this tends to
> > >affect web servers more than mail servers, it's
> still the reason they
> > >build load balancers.
> >
> > Note that DNS-based load balancers have extremely
> short TTL's, which will
> > slow the average access time due to loss of
> caching.
> >
> > > 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.
> >
> > why?
> >
> > >Again, this is a much bigger problem on a high
> volume network.
> >
> > why?
> Because sooner or later the authoritative DNS server
> is going to forget
> what it told my resolver, and will give me the first
> item in the list.
> High volume networks have more servers, and NS1
> doesn't have a clue what
> NS2 just told me. Let alone NS3, NS4 and NS5. The
> more infrequent my
> queries, the more apt I am to be given the address
> of the same server
> twice in a row. A network that handles a million DNS
> queries an hour
> will dequeue old information more often than one
> that answers a 1000 DNS
> queries a day, once again improving my ability to
> get the address of the
> same server twice in a row.
>
> >
> > > > ok, your answer is right, for the wrong
> reasons. :))
> > >A different way of arriving at the same
> conclusion perhaps?
> >
> > yes, my right way, and your wrong way. :))
> That's not what I get from RFC 974 :)
>
> >
> > >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.
> >
> > CNAME´s are to be avoided.
> >
> > > Pick the MTA of your choice, go to their web
> site, and you are
> > >bound to find something about CNAME loops in the
> FAQ.
> >
> > CNAME´s are to be avoided.
> >
> > Much more common is an MX hostname being an ip
> address.
> >
> > Len
> >
> > http://MenAndMice.com/DNS-training
> > http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4
> & W2K
> > http://IMGate.MEIway.com : Build free, hi-perf,
> anti-abuse mail gateways
> >
> 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
______________________________________________________________________
Do You Yahoo!?
Il tuo indirizzo gratis e per sempre @yahoo.it su http://mail.yahoo.it
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?20010916170301.66091.qmail>