Address Sorting

This is a somewhat arcane subject simply because few people need features related to the address sorting functions in BIND. While address sorting was the default in older versions of BIND 4, newer versions of BIND 4 and BIND 8 use the address round-robin scheme described in Chapter 3 in the section "DNS Round Robin and Load Distribution."

Address sorting in BIND is the process in which, if the host being queried about has several addresses and one address is closer to the client, that address should be returned first. This is based on the theory that using the address closer to the client is more optimal, which it usually is. This, of course, assumes that the client does not hash the answer, parse it backward, or sort it as it is allowed to do. That would ruin the whole scheme. Additionally, the nameserver does not really have any knowledge of the network topology; it can only make guesses based on (possibly incorrect) assumptions about subnetting and so on. Because of this, sorting by the server has been found to be somewhat lacking in merit, and the round-robin scheme is seen as more desirable (so it is the default). Instead, new stub resolvers now support a sorting option in /etc/resolv.conf. This makes more sense because the administrator of the host does know things about the network topology and can set up the correct sorting options if necessary. Please see your resolv(5) or resolver(5) man page for more information about the resolv.conf sortlist option.

Of course, installing a sortlist on each and every client in your network can be a lot of work. Therefore, the old sorting behavior in BIND can still be achieved through the sortlist and topology options, enabling you to perform centralized address sorting instead of decentralized sorting in the stub resolvers.

Sortlist

A sortlist defines the preferred addresses for addresses or subnets. This example is from the named.conf man page:

 sortlist {     { localhost; localnets; };         { localnets; }; }; 

The sortlist consists of pairs. First in the pair is a list of addresses to match, and second is a list of addresses to prefer. In the previous example, one pair exists. When a query comes in from a host matching the predefined ACLs localhost or localnets, any A records matching the localnets ACL is sorted before any other A records matching the query. Queries from anyone else are sorted according to the rrset-ordering for the records (round-robin by default). The previous sortlist is quite reasonable for a small network of one subnet. If penguin.bv has two www.penguin.bv servers, one at an ISP and one on its own network, this sortlist ensures that when the penguin employees type www.penguin.bv/, they will use their local server, and not their Internet line. In addition, it ensures that users outside penguin.bv get a round-robined random address as usual. If you want to pursue this subject, please see Appendix A, "named.conf Man Page," which has a much more elaborate, commented example.

Topology

Topology overrides your nameserver's preferences for remote nameservers. BIND bases its choice of which remote nameservers to use on the RTT servers with good RTT records get chosen over servers with worse RTT records. This is exactly what we want in most cases. But in some cases, such as when one line costs more to put traffic on, one line is more liable to be overloaded, or a nameserver is more likely to be down, it makes sense to prefer nameservers based on another metric.

The topology statement assigns distances based on the order in the topology list. A negated element gets assigned the maximum distance. Here is an example for ns.penguin.bv:

 topology {     192.168.55/24;      // Local net is preferred     !192.168.56.0/25;   // But the emperor-net is overloaded     192.168.226/24;     // Walruss-net }; 

The local net is preferred before the walruss net, and the emperor.penguin.bv net is least preferred, being negated. This is the default topology list in BIND 8:

 topology {     localhost;     localnets; }; 

Sorting Is Out of Band

All record sorting configuration is out of band. BIND does not communicate sorting requirements to caching or slave servers. Most often, slave and cache servers round robin the records. If they are to sort addresses, the same (or at least analogous) sortlist and rrset-order options have to be installed on them as on the master.