priority with A record?

Kevin Darcy kcd at chrysler.com
Wed Apr 6 16:24:15 UTC 2011


In theory, what you'd do is set a "fixed" rrset-order, and then 
rearrange the actual RRset (e.g. using Dynamic Update) whenever the 
loads/availabilities change. You'd need to set your TTL on the RRset 
appropriately to ensure that caching resolvers see the changes in a 
timely fashion. I'll reiterate that I've never actually used rrset-order 
in production, so all of this is conjecture on my part.

Sortlist would be if you wanted to optimize the load-balancing according 
to the (presumed) location of the client. This would be even uglier, 
because you'd have to dynamically change the sortlist definitions (in 
named.conf) themselves to reflect different loadings/availabilities, 
which would require reloading or reconfig'ing the named instance. Even 
worse, since sortlists are global to the whole nameserver instance (or 
view?) you might need to split up your DNS hosting functions between 
multiple named instances (potentially listening on different physical or 
virtual interfaces), or different views, if you wanted to load-balance 
multiple names independently of each other. This would quickly become 
very difficult to manage.

Potentially it might be possible to use sortlists and rrset-order 
together, depending on how they interact (which I don't really know, 
since, again, I've never used rrset-order in production, and frankly it 
hurts my brain to think how they would interact, if at all).

It's all a moot point for Internet DNS names anyway, since the presence 
of intermediate resolvers mucking up your sortlist-based and/or 
rrset-order-based address sorting, makes this approach a non-starter.

                                                                         
                                                                         
                                         - Kevin


On 4/6/2011 5:37 AM, iharrathi.ext at orange-ftgroup.com wrote:
> 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.
> ********************************************************************************
>
>
>
>
>





More information about the bind-users mailing list