 | Chapter 10 Advanced Features and Security |  |
| Chapter 10 Advanced Features and Security | |
When you are contacting a host that has multiple network interfaces, using a particular interface may give you better performance. If the multihomed host is local and shares a network with your host, one of the multihomed host's addresses is "closer." If the multihomed host is remote, you may see better performance by using one of the interfaces instead of another, but often it doesn't matter much which address is used. In days 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 improvement by preferring 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 the section called "The sortlist Directive" in Chapter 6, Configuring Hosts.) 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 won't be optimal for every resolver it services. Resolver address sorting was added at 4.9. If your resolver (not your name server) is older than 4.9, you are out of luck. You'll have to make do with address sorting at the name server, which was introduced in 4.8.3.
We should also mention that address sorting is not supported in BIND 8. For BIND 8, the developers removed address sorting because they believed that it had no place in the server.
Let's deal with the local multihomed host first. Suppose you have a source host (i.e., a host that keeps your master sources) 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 will experience better performance if they use the source host's interface to network A. Likewise, hosts on network B would benefit from using the source host's interface to network B for the address of the NFS mount.
In Chapter 4, Setting Up BIND, 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 and wh253 for wormhole) 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, they are 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 out all the interface addresses of the host it is running on. BIND extracts the network numbers from these addresses to create the default sort list. When a query is received, BIND checks if 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, 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 will get 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 will get an answer back with notorious's network B address first. Both hosts are on network B. In both of 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 (see Figure 10.3).
Let's change the situation slightly. Suppose the name server is running on gaslight. When spellbound queries gaslight for notorious's address, spellbound will see 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.
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 domain has networks 192.249.249 and 192.253.253. Let's add a connection to net 10 (the old ARPAnet). The remote host being contacted has two network connections, one to network 10 and one to network 26. This host does not route to network 26, but for special reasons it has a network 26 connection. Since the router to network 26 is always overloaded, you'll get better performance by using the remote host's net 10 address. Figure 10.4 shows this situation.
If a user on terminator is contacting reanimator, it's preferable to use the network 10 address, because access through gateway B to the network 26 address will be slower than the direct route. Unfortunately, the name server running on terminator will not intentionally place network address 10 first in the list when it looks up the addresses for reanimator; the only network that terminator is attached to is 192.249.249, and so it doesn't know that network 10 is "closer" than network 26. This is where the sortlist boot file entry comes into play. To indicate a preference for network 10 addresses, add the following line to named.boot:
sortlist 10.0.0.0
The sortlist entries are appended to the default sort list. With this sortlist entry, the sort list on terminator now contains networks 192.249.249 and 10. Now, when a user on terminator queries the name server on terminator, and the name server sorts the response because the query is local, the name server will check for addresses on the 192.249.249 network and place them first in the response. If there are no addresses on network 192.249.249, it will check for network 10 addresses and place them first in the response. This solves the problem we described earlier - when reanimator is looked up, its network 10 address will be placed first in the response.
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 will be 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 subnet sortlist entry is discarded.
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.4 System Tuning |  | 10.6 Preferring Name Servers on Certain Networks |