RoundRobin question

[Kevin Darcy]

William Stacey wrote:

>Was wondering how round-robin is implemented at a high level.  Does each rr
>in the zone have an integer value so that each time a rrset is returned for
>say (www.mydomain.com A) each record will have some key that a sort is run
>against that record set?  Then the record set is updated so the first rr
>becomes the last on next sort?  Maybe the first rr get the count value of
>the rrset so it is forced to the bottom and the rest get a sync starting at
>1?  Just curious as was having talk on this with someone and am curious.
>
The fallacy here is that true "round robin" actually exists in modern 
versions of BIND. It doesn't. The A records are stored in memory in the 
same order they are read from the zone file, but for both "cyclic" and 
"random" ordering, the first record of every response is always chosen 
at random. The only difference between the two orderings is that the 
second through _nth_ records of the response are given out randomly in 
the case of "random", but according to the stored order, rotated, in the 
case of "cyclic". If you have only 2 A records, the first record is 
random, there is no choice but to present the other record after it, so 
there is no difference whatsoever between "cyclic" and "random".

Note that if you're trying to use A-record ordering for 
load-balancing/failover with more than 2 A records, "cyclic" is 
basically the worst of both worlds: not only do you get the intermittent 
"spiking" associated with random ordering, because the first A record 
(which clients will always use under normal circumstancees) is chosen 
randomly, but in the case of failure, the "next" A record (according to 
the rotated ordering) will get up to twice the normal volume because it 
gets all of the failover traffic. "random" is actually *better* for this 
application, but still sub-optimal.

Why doesn't BIND implement true round robin? Because the developers 
don't want to bother keeping track of state information above and beyond 
the actual ordering of the records themselves (and it would be 
prohibitively expensive to actually rearrange the records in memory 
every time an answer was given). *If* the developers were interested in 
keeping some state around, I'd like to see an implementation of 
"permuted" ordering, where every possible permutation of A records is 
presented with equal frequency. That should eliminate the "spiking" 
problem -- since the first record of each response will get equal (or 
very nearly equal) time -- while at the same time minimizing the 
"failover skewing" problem (since the second record in every response 
will also be evenly spread among the available A records). But I'll get 
off my soapbox now... :-)

                                                                         
                                             - Kevin