 |  |
10.9. Preferring Name Servers on Certain Networks
BIND 8's topology feature is somewhat similar to sortlist, but it applies only to the process of choosing name servers. (BIND 9 doesn't support topology as of 9.1.0.) Earlier in the book, we described how BIND chooses between a number of name servers that are authoritative for the same zone by selecting the name server with the lowest roundtrip time (RTT). But we lied -- a little. BIND 8 actually places remote name servers in 64-millisecond bands when comparing RTT. The first band is actually only 32 milliseconds wide (there! we did it again), from zero to 32 milliseconds. The next extends from 33 to 96 milliseconds, and so on. The bands are designed so that name servers on different continents are always in different bands.The idea is to favor name servers in lower bands but to treat servers in the same band as equivalent. If a name server compares two remote servers' RTTs and one is in a lower band, the name server chooses to query the name server in the lower band. But if the remote servers are in the same band, the name server checks to see whether one of the remote servers is topologically closer.
So topology lets you introduce an element of fudge into the process of choosing a name server to query. It lets you favor name servers on certain networks over others. Topology takes as an argument an address match list, where the entries are networks, listed in the order in which the local name server should prefer them (highest to lowest). Therefore:
topology {
15/8;
172.88/16;
};You can also negate entries in the topology address match list to penalize name servers on certain networks. The earlier in the address match list the negated entry matches, the greater the penalty. You might use this to keep your name server from querying remote name servers on a network that's particularly flaky, for example.
|  | |
| 10.8. Name Server Address Sorting |  | 10.10. A Nonrecursive Name Server |
