priority with A record?

Wed Apr 6 09:37:33 UTC 2011

Thanks Kevin for the answer,
But rrset-order, can only disble the round robin (cyclic=round robin | random= random | fixed=disable round robin)
And sorlist prioritise basing on IP of the client, i don't see anyway how to send( for example) 75% of http traffic to bigserver1.mysite.com and 25% of traffic to smallserver1.mysite.com
And for the SRV which make exacly what i want, it's not supported by browser.
May be with bind10 we will have this feature for A record like what we have now for MX!

Thanks.
Issam HARRATHI

Date: Tue, 05 Apr 2011 12:40:22 -0400
From: Kevin Darcy <kcd at chrysler.com>
Subject: Re: priority with A record?
To: bind-users at lists.isc.org
Message-ID: <4D9B45F6.9090301 at chrysler.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

On 4/5/2011 8:23 AM, iharrathi.ext at orange-ftgroup.com wrote:
> Hi,
> can i make priority on a A or NS record? Since with round robin if i 
> put  the same record record 2 or 3 time, Bind ignore the duplicates 
> Records, means
>  this:
>
> wikipediaNSns2.wikimedia.org.
>
> wikipediaNSns0.wikimedia.org.
>
> is the same like this:
>
> wikipediaNSns2.wikimedia.org.
>
> wikipediaNSns0.wikimedia.org.
>
> wikipediaNSns0.wikimedia.org.
>
> In this 2 case it will send 50% of traffic to ns2 and 50% to ns0;
>
> Is there anyway to enable priority on A or NS record?
>
> Thanks.
>
>
For NS records, there is no way to do this in BIND, and it's completely unnecessary anyway, since every major DNS full-resolver implementation will keep track of how fast nameservers respond -- based on round-trip times, known as "RTT"s -- and prefer faster-responding nameservers over slower-responding ones. So the load spreads itself automatically, and failures -- which are assessed as really "bad" performance -- are routed around.

For A/AAAA records, there are mechanisms to control the order in which the records are presented. See "sortlist" and "rrset-order" (not sure that "rrset-order" even exists in later versions of BIND, since I've never used it in production). However, these are only practical on tightly-controlled intranets, where all of the BIND-instance configurations can be kept in sync with each other, otherwise one BIND instance may undo the careful address-record ordering that another performs. rrset-order and sortlist are pretty much useless for Internet names, since the vast majority Internet users get their DNS through intermediate resolvers, which will usually randomize or round-robin the responses whenever they are answering from their caches.

As another poster pointed out, SRV records provide the capability for the domain owner to implement per-name failover and "weighting" of targets, in the DNS data itself. But, thusfar the DNS community hasn't had much success getting client-software developers (e.g. browser
developers) to adopt SRV record support. Meanwhile, certain network-hardware companies (including among others a certain huge router
vendor) rake in big money with their sledgehammer "load-balancer device" 
approach to the problem. There are software approaches to network load-balancing as well, but I have no direct experience with those.

                 - Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110405/abe4dd37/attachment-0001.html>

------------------------------

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************