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