UNIX System Administration Handbook - Evi Nemeth [246]
You can achieve a primitive but effective form of load balancing by assigning a single hostname to several IP addresses (which in reality are different machines):
www IN A 192.168.0.1
IN A 192.168.0.2
IN A 192.168.0.3
Busy web servers such as Yahoo or AltaVista are not really a single machine. They’re just a single name in DNS. A name server that has multiple records for the same name and record type returns all of them to the client, but in round robin order. For example, round robin order for the A records above would be 1, 2, 3 for the first query, 2, 3, 1 for the next, 3, 1, 2 for the third, and so on.
The extended DNS protocol
The original DNS protocol definition dates from the late 1980s and uses both UDP and TCP. UDP is typically used for queries and responses, and TCP for zone transfers between master servers and slave servers. Unfortunately, the maximum packet size that’s guaranteed to work in all UDP implementations is 512 bytes, which is much too small for some of the new DNS security features that must include digital signatures in each packet.
The 512-byte constraint also affects the number and names of the root servers. To make all root server data fit in a 512-byte UDP packet, the number of root servers is limited to 13, and each server is named with a single letter of the alphabet.
Many resolvers issue a UDP query first; then, if they receive a truncated response, they reissue the query over TCP. This procedure gets around the 512-byte limit, but it is inefficient. You might think that DNS should just bail on UDP and use TCP all the time, but TCP connections are much more expensive. A UDP name server exchange can be as short as two packets, one query and one response. A TCP exchange involves at least seven packets: a three-way handshake to initiate the conversation, a query, a response, and a final handshake to close the connection.
In the mid-1990s, the DNS protocol was amended to include incremental zone transfers (like a diff between old and new zone files, inspired by Larry Wall’s patch program), asynchronous notifications (to tell slaves when the master’s data files have been updated), and dynamic updates (for DHCP hosts). These changes added features but did not really address the fundamental transport problem.
In the late 1990s, EDNS0 (Extended DNS, version 0) addressed some of the shortcomings of the DNS protocol in today’s Internet. It lets speakers advertise their reassembly buffer size, supported options, and protocol versions spoken. If the receiving name server responds with an error message, the sender drops back to the original DNS protocol. BIND 9 implements EDNS0 in both the server and the resolver.
16.8 BIND CLIENT ISSUES
Before we dive into the configuration of BIND, let’s outline the chores that are associated with using BIND on the Internet. Table 16.6 summarizes what must be done, for whom, and how often. An entry in the “How often” column that includes the word “distribute” means that you do it once per subnet or architecture and then copy the result to the appropriate hosts with a tool like rdist or rsync.
Table 16.6 BIND installation and maintenance chores
a. But must be redone if the root servers change
See Chapter 18 for more information about distributing files on a network.
Since each host on the network must be a BIND client, we begin our detailed discussion with client-side chores.
Resolver configuration7
Each host on the network has a file called /etc/resolv.conf that lists the DNS servers the host should query. If your host gets its IP address and network parameters from a DHCP server, the /etc/resolv.conf file should be set up for you automatically. Otherwise, you must edit it by hand. The format is:
search domainname ...
nameserver ipaddr
Up to three name servers can be listed. Here’s a complete example:
search cs.colorado.edu colorado.edu ee.colorado.edu
nameserver