modifying bind to do weighted round-robin

[Jay C Austad]

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?

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



----------
Jay Austad
Network Administrator
CBS Marketwatch
612.817.1271
jaustad at bigcharts.com
http://cbs.marketwatch.com
http://www.bigcharts.com

[Barry Margolin]

In article <6C09D9B03136D311839800902762696501C7868D at mpls.marketwatch.com>,

Post by Jay C Austad
I really need to get bind to do weighted round-robin.

Why does it have to be BIND? If you're doing this for marketwatch.com, I
think they should be be able to afford a Distributed Director or Local
Director, which supports this as well as other useful features like
automatic failover if any of the servers die.

[Kevin Darcy]

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.
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().

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

[Jay C Austad]

We are currently using, and have tried other distributed director type products, but they are not nearly as stable as bind is. We need something simple and reliable. In fact, some of these products have a separate daemon that runs to make sure the nameserver process doesn't die.

All we need is BIND with some sort of nice weighted round robin type functionality.

----------
Jay Austad
Network Administrator
CBS Marketwatch
612.817.1271
jaustad at bigcharts.com
http://cbs.marketwatch.com
http://www.bigcharts.com






-----Original Message-----
From: Barry Margolin [mailto:barmar at bbnplanet.com]
Sent: Wednesday, March 22, 2000 6:07 PM
To: comp-protocols-dns-bind at moderators.isc.org
Subject: Re: modifying bind to do weighted round-robin


In article <6C09D9B03136D311839800902762696501C7868D at mpls.marketwatch.com>,

Post by Jay C Austad
I really need to get bind to do weighted round-robin.

Why does it have to be BIND? If you're doing this for marketwatch.com, I
think they should be be able to afford a Distributed Director or Local
Director, which supports this as well as other useful features like
automatic failover if any of the servers die.

[D. J. Bernstein]

The DNScache package includes a load-balancing server, pickdns:

http://cr.yp.to/dnscache/faq/pickdns.html

I haven't added any special weighting features, but pickdns doesn't mind
repeated IP addresses.

---Dan

[Jay C Austad]

Post by Kevin Darcy
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?

Well, right now, the commercial load balancing dns servers only hand out one ip at a time, instead of all of them. If a large ISP, like AOL, caches just that one ip, it's going to generate a significantly larger amount of traffic just on that one server (or cluster). At least with multiple ip's being handed out, it will round-robin (not weighted though) and distribute the load a little better. Right now, we'll see one cluster get pounded for several minutes, and then another will get pounded for several minutes right after, even though the ratio is being set the same to each cluster. The TTL is set very low, so it reduces this sort of behavior, but it still happens for a couple of minutes at a time. By setting the TTL low, we are increasing the load on the nameserver and increasing our traffic, but the amount of dns traffic is insignificant compared to the amount of web traffic going out.

As for my secondary, initially, the zone file can be manually copied across and reloaded when modifications happen to it.

I'd like to get something up and working so I can do some testing on it to see exactly how well it will work.

Jay