modifying bind to do weighted round-robin

[Kevin Darcy]

Jay C Austad wrote:

> I really need to get bind to do weighted round-robin.  I attempted to put lines like the following in:
>
> www     IN      A       10.2.2.2
> www     IN      A       10.2.2.2
> www     IN      A       10.2.2.2
> www     IN      A       10.1.1.1
>
> to send 75% of my traffic to 10.2.2.2, and the other 25% to 10.1.1.1 as a test.  However, when I query the test machine I am running this on, I still get roughly a 50/50 distribution.
>
> I assume there is code that removes duplicates.  I need to either remove that code, or modify the code that rotates the list of ip's after each query.
>
> For example, here's what I want to see when doing nslookups against it, and it would need to work with more than just 2 ip's:
>
> Addresses:  10.2.2.2, 10.1.1.1
> Addresses:  10.2.2.2, 10.1.1.1
> Addresses:  10.2.2.2, 10.1.1.1
> Addresses:  10.1.1.1, 10.2.2.2
> Addresses:  10.2.2.2, 10.1.1.1
> Addresses:  10.2.2.2, 10.1.1.1
> Addresses:  10.2.2.2, 10.1.1.1
> Addresses:  10.1.1.1, 10.2.2.2
> Addresses:  10.2.2.2, 10.1.1.1
> Addresses:  10.2.2.2, 10.1.1.1
>
> How would I go about doing this?  Has anyone done it yet?  Where in the code would I start looking?

The RRset sorting routines in BIND 8 are in finddata().

> Even better would be the above mod, but instead of having to enter multiple lines for each ip, be able to do the following:
>
> www     IN      A       10.2.2.2                3
> www     IN      A       10.1.1.1                1

Ouch! That would be a radical change to the zonefile-parsing routines, since it would require an extra check for every RR. Perhaps some sort of directive ($WEIGHT?) might be a better way
to go.

Before you go off and write a bunch of code, though, you should be aware that the "official" way to deal with these kinds of ordering issues -- other than paying mucho dinero for a
commercial "load-balancing" product, of course --  is to use SRV records, which have preferences and weighting built-in. The only problem is, no clients except perhaps Win2K's use
SRV records, and I believe Win2K only uses them for LDAP and Kerberos (i.e. Defective Directory) access. So, unless this is for AD, you're between a rock and a hard place: there is no
support in the protocol or the codebase for what you are proposing, because SRV records are supposed to be the strategic solution, but you can't use SRV records because practically
no-one groks them. Moreover, even if you implement advanced weighting/ordering on the master, what are you going to do about slaves, or, even worse, about intermediate caching servers,
which are going to eliminate duplicate records and non-weightedly round-robin their cached answers? Reducing TTL values is a blecherous way of dealing with the caching servers, I
suppose, but at what cost?

In the absence of SRV acceptance, which requires global changes at the application level, what is really needed IMO is a record type to specify RRset ordering; something that only
nameservers would care about, i.e. no client code changes, but which would at least propagate normally like any other record type so that all nameservers, including slaves and
caching-only nameservers, would know the ordering/weighting to apply to a given RRset. I'm working on a proposal for something like that, but even if accepted (a *big* "if"), it would be
years before it was widely deployed. Hardly useful for your short-term requirements. Sorry I can't be more encouraging.

                                                                                                                                                    - Kevin