10.8 Name Server Address Sorting

Sometimes, neither round robin nor another configurable order is what you want. When you are contacting a host that has multiple network interfaces and hence multiple IP addresses, choosing a particular interface based on your host's addressmay give you better performance. No rrset-order substatement can do that for you.

If the multihomed host is local and shares a network or subnet with your host, one of the multihomed host's addresses is "closer." If the multihomed host is remote, you may see better performance using one interface instead of another, but often it doesn't matter much which address is used. In days long past, net 10 (the former ARPAnet "backbone") was always closer than any other remote address. The Internet has improved drastically since those days, so you won't often see a marked performance improvement when using one network over another for remote multihomed hosts, but we'll cover that case anyway.

Before we get into address sorting by a name server, you should first look at whether address sorting by the resolver better suits your needs. (See Section 6.1.5 in Chapter 6.) Since your resolver and name server may be on different networks, it often makes more sense for the resolver to sort addresses optimally for its host. Address sorting at the name server works fairly well, but it can be hard to optimize for every resolver it services. Resolver address sorting was added in BIND 4.9, though, so if your resolver (not your name server) is older than 4.9 or isn't BIND at all, you're out of luck. You'll have to make do with address sorting at the name server, which was introduced in 4.8.3.

In an uncommon turn of events, the name server's address sorting feature was removed in early versions of BIND 8, primarily because of the developers' insistence that it had no place in the name server. The feature was restored—and in fact enhanced—in BIND 8.2. BIND 9.1.0 is the first BIND 9 release to support address sorting.

10.8.1 BIND 4 Address Sorting

BIND 4's address sorting, while simpler to configure than BIND 8's, is more complex to describe because it does quite a bit automatically, without any configuration. Let's cover it first.

10.8.1.1 Local multihomed hosts

Let's deal with the local multihomed host first. Suppose you have a source host (i.e., a host that keeps your master source code) on two networks, cleverly called network A and network B, and this host uses NFS to export filesystems to hosts on both networks. Hosts on network A experience better performance if they use the source host's interface to network A. Likewise, hosts on network B benefit from using the source host's interface to network B for the address of the NFS mount.

In Chapter 4, we mentioned that BIND returns all the addresses for a multihomed host. There was no guarantee of the order in which a DNS server would return the addresses, so we assigned aliases (wh249.movie.edu and wh253.movie.edu for wormhole.movie.edu) to the individual interfaces. If one interface was preferable, you (or more realistically, a DNS client) could use an appropriate alias to get the correct address. You can use aliases to choose the "closer" interface (e.g., for setting up NFS mounts), but because of address sorting, that's not always necessary.

BIND 4 servers, by default, sort addresses if one condition holds: if the host that sent the query to the name server shares a network with the name server host (e.g., both are on network A), then BIND sorts the addresses in the response. How does BIND know when it shares a network with the querier? It knows because when BIND starts up, it finds all the interface addresses of the host it's running on. BIND extracts the network numbers from these addresses to create the default sort list. When a query is received, BIND checks whether the sender's address is on a network in the default sort list. If it is, then the query is local and BIND sorts the addresses in the response.

In Figure 10-3, let's assume that there is a BIND 4 name server on notorious. The name server's default sort list would contain network A and network B. When spellbound sends a query to notorious looking up the addresses of notorious, it gets an answer back with notorious 's network A address first. That's because notorious and spellbound share network A. When charade looks up the addresses of notorious, it gets an answer back with notorious 's network B address first, because both hosts are on network B. In both these cases, the name server sorts the addresses in the response because the hosts share a network with the name server host. The sorted address list has the "closer" interface first.

Figure 10-3. Communicating with a local multihomed host

Let's change the situation slightly. Suppose the name server is running on gaslight. When spellbound queries gaslight for notorious 's address, spellbound sees the same response as in the last case because spellbound and gaslight share network A, which means that the name server will sort the response. However, charade may see a differently ordered response, since it does not share a network with gaslight. The closer address for notorious may still be first in the response to charade, but only because of luck, not name server address sorting. In this case, you'd have to run an additional name server on network B for charade to benefit from BIND 4's default address sorting.

As you can see, you benefit by running a name server on each network; not only is your name server available if your router goes down, it also sorts addresses of multihomed hosts. Because the name server sorts addresses, you do not need to specify aliases for NFS mounts or network logins to get the best response.

10.8.1.2 Remote multihomed hosts

Suppose that your site often contacts a particular remote site or a "distant" local site, and that you get better performance by favoring addresses on one of the remote site's networks. For instance, the movie.edu zone comprises the networks 192.249.249/24 and 192.253.253/24. Let's add a connection to network 10/8 (the old ARPAnet). The remote host being contacted has two network connections, one to network 10/8 and one to network 26/8. This host does not route to 26/8, but for special reasons it has a connection to it. Since the router to 26/8 is always overloaded, you'll get better performance using the remote host's 10/8 address. Figure 10-4 shows this situation.

Figure 10-4. Communicating with a remote multihomed host

If a user on terminator.movie.edu contacts reanimator.movie.edu, it's preferable to use the 10/8 address because access through gateway B to the 26/8 address is slower than the direct route. Unfortunately, the name server running on terminator.movie.edu will not intentionallyplace a 10/8 address first in the list when it looks up the addresses for reanimator.movie.edu; the only network that terminator.movie.edu is attached to is 192.249.249/24, so it doesn't know that 10/8 is "closer" than 26/8. This is where the sortlist directive comes into play. To indicate a preference for addresses on network 10/8, add the following line to named.boot :

sortlist 10.0.0.0

The sortlist arguments are appended to the default sort list. With this sortlist directive, the sort list on terminator.movie.edu now contains networks 192.249.249/24 and 10/8. Now, when a user on terminator.movie.edu queries the name server on terminator.movie.edu and the name server sorts the response because the query is local, the name server will check for addresses on the 192.249.249/24 network and place them first in the response. If there are no addresses on 192.249.249/24, it will check for 10/8 addresses and place them first in the response. This solves the problem we described earlier; now when reanimator.movie.edu is looked up, its address on network 10/8 will be placed first in the response.

10.8.1.3 Address sorting on subnetted networks

Subnetted networks change address sorting only slightly. When the name server creates its default sort list, it adds both the subnet number and the network number to the list. Like before, when the query is local and the name server sorts the response, the common subnet address is placed first. Unfortunately, not everything is perfect—you can't add sortlist entries for other subnets of your network. Here's why: the name server assumes all the sortlist entries are network numbers (not subnet numbers), and your network number is already on the sort list. Since your network number is already on the list, the sortlist entry for your subnet is discarded.

10.8.1.4 Multiple sortlist entries

One last thing—if you want to add more than one sortlist entry, you must specify them all on the same line, like this:

sortlist 10.0.0.0 26.0.0.0

10.8.2 BIND 8 and 9 Address Sorting

BIND 8.2 and later (as well as 9.1.0 and later) name servers can sort addresses, too. Unfortunately, this isn't automatic, nor is it particularly easy to configure. The key is an options substatement called, naturally, sortlist.

The sortlist substatement takes an address match list as an argument. Unlike address match lists used as access control lists, though, sortlist 's has a very specialized interpretation. Each entry in the address match list is itself an address match list with either one or two elements.

If an entry has only one element, it's used to check the IP address of a querier. If the querier's address matches, then the name server sorts addresses in a response to that querier so that any addresses that match the element are first. Confusing? Here's an example:

options {
	sortlist {
		{ 192.249.249/24; };
	};
};

The only entry in this sort list has just one element. This sort list sorts addresses on the network 192.249.249/24 to the front of responses to queriers that are also on that network.

If an entry has two elements, the first element is used to match the IP address of a querier. If the querier's address matches, the name server sorts addresses in a response to that querier so that any addresses that match the second element come first. The second element can actually be a whole address match list of several elements, in which case the first address added to the response is the one that matches first in the list. Here's a simple example:

options {
	sortlist {
		{ 192.249.249/24; { 192.249.249/24; 192.253.253/24; }; };
	};
};

This sort list applies to queriers on 192.249.249/24 and sends them addresses on their own network first, followed by addresses on 192.253.253/24.

The elements in the sort list specification can just as easily be subnets or even individual hosts:

options {
	sortlist {
		{ 15.1.200/21;       // if the querier is on 15.1.200/21
			{ 15.1.200/21;  // then prefer addresses on that subnet
			15/8; };        // or at least on 15/8
		};
	};
};