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.
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.
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
};
};
};
|
