From owner-freebsd-isp Sun Sep 16 10: 3:17 2001 Delivered-To: freebsd-isp@freebsd.org Received: from web20106.mail.yahoo.com (web20106.mail.yahoo.com [216.136.226.43]) by hub.freebsd.org (Postfix) with SMTP id B7DB437B405 for ; Sun, 16 Sep 2001 10:03:01 -0700 (PDT) Message-ID: <20010916170301.66091.qmail@web20106.mail.yahoo.com> Received: from [62.11.66.59] by web20106.mail.yahoo.com via HTTP; Sun, 16 Sep 2001 19:03:01 CEST Date: Sun, 16 Sep 2001 19:03:01 +0200 (CEST) From: =?iso-8859-1?q?Fabrizio=20Ravazzini?= Subject: Re: Mail Server - Round Robin Load Distribution To: Bob Martin Cc: freebsd-isp@freebsd.org In-Reply-To: <3BA3A4C1.C344A6F@buckhorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 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