DNS Round Robin

Kevin Darcy kcd at daimlerchrysler.com
Tue Feb 24 22:33:14 UTC 2004


James Sebastian wrote:

>Hi all,
>
>I am new to this forum. I am struck with DNS round robin.
>
>Kevin Darcy <kcd at daimlerchrysler.com> wrote in message news:<bvc8f9> >beta1.company.com.	30	IN	A	192.168.1.1
>  
>
>>>beta2.company.com.	30	IN	A	192.168.1.2
>>>beta3.company.com.	30	IN	A	192.168.1.3
>>>beta.company.com.	30	IN	CNAME		beta1.company.com.
>>>beta.company.com.	30	IN	CNAME		beta2.company.com.
>>>beta.company.com.	30	IN	CNAME		beta3.company.com.
>>>      
>>>
>
>If I want to get responses in round robin fashion strictly how should
>I setup bind.
>
>I set up bind as per the instruction of DNS cook book
>like
>
>WWW     IN    A     x.x.x.1
>        IN    A     x.x.x.2
>         IN   A     x.x.x.3
>         IN   A     x.x.x.4
>
>But nslookup returns the answer in random order only. 
>
>Learning it beahves as cyclic random, I recnfigured the DNS using bind
>8.4.4 and used rrset-order and multiple-cnames.
>
>multiple-cnames yes;
>rrset-order {
>        class IN type A name "hp110.test.com" order cyclic;
>        };
>
>I tried order cyclic and fixed. But lookup results is not in round
>robin fashion.
>
>I understand by round robin, I should get answeres in the oder 1,2,3,4
>; 2,3,4,1; 3,4,1,2  etc etc...But it always comes in random order
>(like 1,2,3,4; 4,5,1,2; 4,5,1,2; 3,4,1,2 etc..)
>
>I tried even fixed which I expected results in fixed manner, but I am
>not getting that way..
>
>Can any one of you tell me where I am making mistakes and I need to
>setup DNS to respond in the order 1,2,3,4; 2,3,4,1; 3,4,1,2; 4,1,2,3
>for testing of a project.
>
There is no *true* round-robin ordering in modern versions of BIND. The 
closest approximation is "cyclic", which as you have noticed picks the 
first record at random and then orders the remaining records in 
cyclic-sequential order, relative to that record. "True" round-robin 
requires keeping state about the ordering of the last answer given, and 
there is currently no slot for that state information in the 
resource-record data structure. So this would be a non-trivial change to 
the code, and its usefulness is questionable, especially in light of the 
skewing effects when one of the resources associated with one of the A 
records fails, thus causing up to 2x the traffic to the next resource in 
the chain. (Of course, this same skewing problem applies to "cyclic" 
ordering too, but at least it doesn't require extra state information).

Now *permuted* ordering -- where every possible permutation of the 
records is presented with equal frequency, would be somewhat valuable 
(because it gives "equal time" to each A record but without such severe 
skewing effects), but requires keeping even more state information 
(actually it goes up factorially with the number of records, which is a 
huge problem for large record sets, where it would be most useful).

                                                                         
                                          - Kevin




More information about the bind-users mailing list