DNS Round Robin and Load Distribution

In these days of exponential growth of Internet users any moderately successful Web site will receive more traffic than one machine can handle. There are many ways to cope with this, and the most robust use special hardware to do load distribution among multiple servers. There is a quite good, very cheap, and somewhat un-robust way to do it with DNS as well: DNS round robin. This was first implemented by a special load distributing DNS server implementation, but was also implemented in a late version of BIND 4. The trick is simply this: When a service is served by many servers all containing the same content simply enter multiple A records for the domain name for the service. This trick works quite well. I have never made any measurements myself, but people that have have told me they see loads on the load-balanced servers within 5% of each other. The Norwegian newspaper VG uses this for its Web service http://www.vg.no:

 $ dig www.vg.no +pfmin ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>>HEADER<<<- opcode: QUERY, status: NOERROR, id: 64365 ;; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;;      www.vg.no, type = A, class = IN ;; ANSWER SECTION: www.vg.no.              2h58m7s IN A    195.139.5.235 www.vg.no.              2h58m7s IN A    195.139.5.232 www.vg.no.              2h58m7s IN A    195.139.5.233 www.vg.no.              2h58m7s IN A    195.139.5.236

If you repeat the query several times you should be able to see that what record comes first changes. In ancient BINDs the first record in the list would always be the first in the answer. When DNS round robin was first implemented in BIND it was just that, a round robin. For each query the next A record would be first, and the previous first would be last. A simple rotation through the records in other words. Current versions of BIND randomize which record is served first, but always conserves their order.

The reason why this works is quite simply that Web browsers, ftp clients, telnet clients, and so on will all try the first address returned. Many Web browsers will not try any subsequent records returned, they will just return "Failed to get page" when the first fails. Traditional FTP and telnet clients will try the next address if the first fails. So, what record BIND returns first determines which Web server will be used.

The way to set up this is un-exiting. If we install another Web server at 192.168.55.10 in penguin.bv the WWW part of the zone file would get two A records for each name that refers to the Web server, like this:

 www             A       192.168.55.3                 A       192.168.55.10 @               A       192.168.55.3                 A       192.168.55.10 

The main problem with this is that DNS does not know when one of your servers go down, and it cannot be taught how to do it either. You can fix this by using dynamic DNS updates (see Chapter 9, "Dynamic DNS"), to add and delete A records as servers fail and reappear. An interesting project using such techniques for Web service, although not with BIND, but with a custom DNS server, is Eddie. You can find more information about Eddie at http://www.eddieware.org/.

If you check Appendix A, "named.conf Man Page," you will see an extensive section about "Resource Record Sorting." You will observe that based on the source of the query you can give any record first or any lower priority as required by network topology for example. These features will very seldom be needed by anyone.

You can control whether BIND uses round robin, fixed ordering or completely random ordering. Round robin is the default, but sometimes fixed and random are appropriate as well. Notice that this only affects your own nameserver. The slaves, and most notably, the caching servers are not affected by this. Because the default is round robin they will all likely use round robin. This directive goes in named.conf inside the options clause:

 options {         …         rrset-order { class ANY type ANY name "*" order fixed ; };         … }; 

The previous example causes all records served by the nameserver to have fixed order. Class is one of the record classes, of which ANY and IN are most interesting for us. Type is the record type, for example A, NS, CNAME, or ANY. Name is the suffix of the names that will match this rule, or "*" for all names. Order is the order in which records will be served, possible values are fixed, random, and cyclic. There might only be one rrset-order directive, but that one might contain several class … clauses, which will be searched in order for a match. To do something special for www.penguin.bv this is the clause:

 class ANY type A name www.penguin.bv order random; 

If there are any rules matching cached domain names it will affect them as well as the zones you're authoritative for. That might not be what you intended.

Also note that a few folks have used multiple CNAME records instead of multiple A records for this kind of load balancing. This is forbidden by default in BIND 8, but see the next section.