3.29 Configuring DNS to Let Clients Find the Closest Server

3.29.1 Problem

You want to set up DNS so that your clients (e.g., FTP NFS or NTP clients) can find the server closest to them.

3.29.2 Solution

If you don't have many servers, and it's relatively easy to determine which server is closest to a client given that client's address, use the sortlist options substatement. This allows you to configure a sortlist: a set of rules that determine, based on the address from which a query is received, which A records to return first in the response to that query.

Say, for example, that you have three networks: 192.168.0/24, 192.168.1/24, and 192.168.2/24. For clients on 192.168.0/24, servers on 192.168.0/24 are -- fairly obviously -- closest. The next closest servers are those on 192.168.1/24. For clients on 192.168.1/24, again, servers on the same network, 192.168.1/24, are closest, followed by servers on 192.168.0/24. Finally, for clients on 192.168.2/24, servers on the same network are closest, but servers on 192.168.0/24 and 192.168.1/24 are equally close.

A sortlist substatement that would return the A record of the closest server first would look like this:

options {
    directory "/var/named";
    sortlist {
        { 192.168.0/24; { 192.168.0/24; 192.168.1/24; 192.168.2/24; }; };
        { 192.168.1/24; { 192.168.1/24; 192.168.0/24; 192.168.2/24; }; };
        { 192.168.2/24; { 192.168.2/24; { 192.168.0/24; 192.168.1/24; };  }; };
    };
};

Though this seems hairy, it's not quite as awful as it looks. The sortlist is an address match list -- just a complicated one. Each term in this sortlist is a pair of address match lists. The first element (192.168.0/24 in the first pair) matches the addresses of some queriers. The name server sorts A records in response to those queriers so that the records appear in the order specified in the second element. For the first pair, that's:

{ 192.168.0/24; 192.168.1/24; 192.168.2/24; };

Or, A records on 192.168.0/24 first, followed by A records on 192.168.1/24, followed by A records on 192.168.2/24, followed by all other A records. If two networks are equally preferred, they're nested further, as in the last pair.

If you have roughly as many servers as you have zones, and each zone has a preferred server, you can take advantage of your resolvers' search lists to let clients find the closest server. For example, say you'd like your NTP clients to find their closest NTP server automatically. You can create an alias, ntp.<domain name of zone>, that always points to the domain name of the closest NTP server for that zone. For example:

ntp.denver.corp.example.    IN    CNAME    tick.boulder.corp.example.

Then configure the NTP clients on the Denver site (which are presumably in the denver.corp.example zone) to use the NTP server named just ntp. As long as the search list on the hosts the NTP clients run on begins with denver.corp.example, they'll use ntp.denver.corp.example as their NTP server.

3.29.3 Discussion

The sortlist substatement is supported in all versions of BIND from 8.2 on, and in BIND 9 from BIND 9.1.0 on.

Sortlists can also have a simpler form, too, with single terms rather than pairs. For example:

options {
    directory "/var/named";
    sortlist {
        { 192.168.0/24; };
        { 192.168.1/24; };
        { 192.168.2/24; };
    };
};

In this form, the name server will sort answers to queries received from 192.168.0/24, for example, so that A records on 192.168.0/24 are first, and similarly for the other two networks.

You can mix the two forms if you like, but be careful, because it's easy to leave out a curly brace ("{" or "}") .

3.29.4 See Also

Section 2.4 for how to create an alias, and Recipes Section 9.3 and Section 9.4 for how to configure a resolver's search list.