Forwarding (DNS and BIND, 4th Edition)

10.5. Forwarding

Certain network connections discourage sending large volumes of traffic off-site, either because the network connection is billed by volume or because it's a slow link with high delay, like a remote office's satellite connection to the company's network. In these situations, you'll want to limit the off-site DNS traffic to the bare minimum. BIND provides a mechanism to do this: forwarders.

Forwarders are also useful if you need to shunt name resolution to a particular name server. For example, if only one of the hosts on your network has Internet connectivity and you run a name server on that host, you can configure your other name servers to use it as a forwarder so that they can look up Internet domain names. (More on this use of forwarders when we discuss firewalls in Chapter 11, "Security".)

If you designate one or more servers at your site as forwarders, your name servers will send all their off-site queries to the forwarders first. The idea is that the forwarders handle all the off-site queries generated at the site, building up a rich cache of information. For any given query in a remote zone, there is a high probability that the forwarder can answer the query from its cache, avoiding the need for the other servers to send queries off-site. You don't do anything to a name server to make it a forwarder; you modify all the other serversat your site to direct their queries through the forwarders.

A primary master or slave name server's mode of operation changes slightly when it is configured to use a forwarder. If a resolver requests records that are already in the name server's authoritative data or cached data, the name server answers with that information; this part of its operation hasn't changed. However, if the records aren't in its database, the name server sends the query to a forwarder and waits a short period for an answer before resuming normal operation and contacting the remote name servers itself. What the name server is doing differently here is sending a recursive query to the forwarder, expecting it to find the answer. At all other times, the name server sends out nonrecursive queries to other name servers and deals with responses that only refer it to other name servers.

For example, here is the BIND 8 and 9 forwarders substatement -- and the equivalent BIND 4 boot file directive -- for name servers in movie.edu. Both wormhole.movie.edu and terminator.movie.edu are the site's forwarders. We add this forwarders substatement to every name server's configuration file exceptthe ones for the forwarders themselves:

options {
	forwarders { 192.249.249.1; 192.249.249.3; };
};

The equivalent BIND 4 directive is:

forwarders 192.249.249.1 192.249.249.3

When you use forwarders, try to keep your site configuration simple. You could end up with configurations that are really twisted.

WARNING: Avoid chaining your forwarders. Don't configure name server A to forward to server B, and server B to forward to server C (or worse yet, back to server A). This can cause long resolution delays and creates a brittle configuration, in which the failure of any forwarder in the chain impairs or breaks name resolution.

10.5.1. A More Restricted Name Server

You may want to restrict your name servers even further -- stopping them from even trying to contact an off-site server if their forwarder is down or doesn't respond. You can do this by configuring your name servers to use forward-only mode. A name server in forward-only mode is a variation on a name server that uses forwarders. It still answers queries from its authoritative data and cached data. However, it relies completely on its forwarders; it doesn'ttry to contact other name servers to find information if the forwarders don't give it an answer. Here is an example of what the configuration file of a name server in forward-only mode would contain:

options {
	forwarders { 192.249.249.1; 192.249.249.3; };
	forward only;
};

On a BIND 4 name server, that would look like:

forwarders 192.249.249.1 192.249.249.3
options forward-only

BIND name servers before 4.9 provide the same functionality using the slave directive instead of the options forward-only directive:

forwarders 192.249.249.1 192.249.249.3
slave

Don't confuse this old use of the term "slave" with the modern use. In BIND 4 name servers, "slave" was synonymous with "forward-only." "Slave" now means a name server that gets zone data from a master server via a zone transfer.

If you use forward-only mode, you must have forwarders configured. Otherwise, it doesn't make sense to have forward-only mode set. If you configure a name server in forward-only mode and run a version of BIND older than 8.2.3, you might want to consider including the forwarders' IP addresses more than once. On a BIND 8 server, that would look like:

options {
	forwarders { 192.249.249.1; 192.249.249.3;
	        192.249.249.1; 192.249.249.3; };
	forward only;
};

On a BIND 4 server, it would be:

forwarders 192.249.249.1 192.249.249.3 192.249.249.1 192.249.249.3
options forward-only

This name server contacts each forwarder only once, and it waits a short time for the forwarder to respond. Listing the forwarders multiple times directs the name server to retransmit queries to the forwarders and increases the overall length of time that the forward-only name server will wait for an answer from forwarders.

However, you have to ask yourself if it ever makes sense to use a name server in forward-only mode. Such a name server is completely dependent on its forwarders. You can achieve much the same results by not running a name server at all; instead, create a resolv.conf file that contains nameserver directives pointing to the forwarders you were using. This way, you're still relying on the forwarders, but now your applications are querying the forwarders directly instead of having a name server query them on the applications' behalf. You lose the local caching and address sorting that the name server would have done, but you reduce the overall complexity of your site's configuration by running fewer name servers.

10.5.2. Forward Zones

Traditionally, using forwarders has been an all-or-nothing proposition: either you use forwarders to resolve every query your name server can't answer itself or you don't use forwarders at all. However, there are some situations in which it would be nice to have more control over forwarding. For example, maybe you'd like to resolve certain domain names using a particular forwarder, but other domain names iteratively.

BIND 8.2 introduced a new feature, forward zones, that allows you to configure your name server to use forwarders only when looking up certain domain names. (BIND 9's support for forward zones was added in 9.1.0.) For example, you can configure your name server to shunt all queries for domain names ending in pixar.com to a pair of Pixar's name servers:

zone "pixar.com" {
	type forward;
	forwarders { 138.72.10.20; 138.72.30.28; };
};

Why would you ever configure this explicitly rather than letting your name server follow delegation from the com name servers to the pixar.com name servers? Well, imagine that you have a private connection to Pixar and you're told to use a special set of name servers, reachable only from your network, to resolve all pixar.com domain names.

Even though forwarding rules are specified in the zone statement, they apply to all domain names that endinthe domain name specified. That is, regardless of whether the domain name you're looking up, foo.bar.pixar.com, is in the pixar.com zone, the rule applies to it because it ends in pixar.com (or is in the pixar.com domain, if you prefer).

There's another variety of forward zone, in a way the opposite of the kind we just showed you. These allow you to specify which queries don't get forwarded. Therefore, it applies only to name servers with forwarders specified in the options statement, which would normally apply to all queries.

These forward zones are configured using a zone statement, but not of type forward. Instead, these are normal zones -- master, slave, or stub -- with a forwarders substatement. To "undo" the forwarding configured in the options statement, we specify an empty list of forwarders:

options {
	directory "/var/named";
	forwarders { 192.249.249.3; 192.249.249.1; };
};

zone "movie.edu" {
	type slave;
	masters { 192.249.249.3; };
	file "bak.movie.edu";
	forwarders {};
};

Wait a minute -- why would you need to disable forwarding in a zone you're authoritative for? Wouldn't you just answer the query and not use a forwarder?

Remember, the forwarding rules apply to queries for all domain names that end in the domain name of the zone. So this forwarding rule really applies only to queries for domain names in delegated subdomains of movie.edu, like fx.movie.edu. Without the forwarding rule, this name server would have forwarded a query for matrix.fx.movie.edu to the name servers at 192.249.249.3 and 192.249.249.1. With the forwarding rule, it instead uses the subdomain's NS records from the movie.edu zone and queries the fx.movie.edu name servers directly.

Forward zones are enormously helpful in dealing with Internet firewalls, as we'll see in the next chapter.

Forwarder Selection
On BIND 8.2.3 name servers, you don't need to list forwarders more than once. These name servers don't necessarily query the forwarders in the order listed; they interpret the name servers in the list as "candidate" forwarders and choose which one to query first based on roundtrip time, the time it took to respond to previous queries.
This is a real benefit if a forwarder fails, especially the first one in the list. Older versions of BIND would keep blindly querying the failed forwarder and waiting before querying the next in the list. BIND 8.2.3 quickly realizes that the forwarder isn't responding and tries another first.
BIND 9 doesn't yet implement this more intelligent form of forwarder selection, unfortunately, though it will retransmit queries to forwarders when necessary.