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.)
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.
 |
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.
|
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.
|
|
