UNIX System Administration Handbook - Evi Nemeth [258]
recursion yes; // internal clients only
zone "example.com" { // complete view of zone
type master;
file "example-internal.db";
};
};
view "external" {
match-clients { any; }; // allow all queries
recursion no; // but no recursion
zone "example.com" { // only "public" hosts
type master;
file "example-external.db";
}
};
If the order of the views were reversed, no one would ever see the internal view. Internal hosts would match the any value in the match-clients clause of the external view before they reached the internal view.
16.10 BIND CONFIGURATION EXAMPLES
Now that we have explored the wonders of named.conf, let’s look at some complete examples. In the following sections, we show three sample configurations:
• A student’s home Linux box
• A university department that uses a three-level forwarding hierarchy
• A company that does web hosting and serves about 2,000 zones
A home Linux box
Rob Braun, a student, has a Linux box at home that provides DNS name service for his domain, synack.net, and for the domains of a couple of friends. He is running BIND 8.2.2-P5. His named.conf file is below. We have added a few comments to the ends of lines.
Rob’s configuration is pretty straightforward. The options are mostly the defaults: a recursive server, files in the usual places, queries and transfers OK, a one-answer transfer format, speaking on port 53, etc. Some control is exercised over the configuration of individual zones. For example, the synack.net zone allows transfers to only one host, and it does not allow dynamic updates.
This name server is the master server for two domains: synack.net and xinetd.org. It’s also a slave server for two friends’ domains: teich.net and rmtai.com. As might be expected in a computer science student’s configuration, the logging section is not the default. It includes mild debugging and curiosity channels modeled after the sample config file shipped with BIND.
/* named.conf file, gw.synack.net */
options {
directory "/var/named";
pid-file "/var/named/named.pid";
};
zone "synack.net" {
type master;
file "synack.forw";
allow-transfer { 198.11.19.15; };
};
zone "xinetd.org" {
type master;
file "xinetd.forw";
allow-transfer { 198.11.19.15; };
};
zone "1.168.192.in-addr.arpa" {
type master; // reverse, for private addresses
file "named.rev";
};
zone "." {
type hint;
file "cache.db";
};
zone "teich.net" {
type slave;
file "teich.net.sec";
masters { 216.103.220.218; };
};
zone "rmtai.com" {
type slave;
file "rmtai.com.sec";
masters { 216.103.220.218; };
};
// Define three logging channels (important syslog messages,
// moderate debugging, and loading zone messages) and
// then map categories to them.
logging {
channel syslog_errors {
syslog local1;
severity error;
};
channel moderate_debug {
severity debug 3; // level 3 debugging
file "foo"; // to file foo
print-time yes; // timestamp log entries
print-category yes; // print category name
print-severity yes; // print severity level
};
channel no_info_messages {
syslog local2;
severity notice;
};
category parser {
syslog_errors;
default_syslog;
};
category lame-servers { null; }; // don't log these
category load { no_info_messages; };
category default {
default_syslog;
moderate_debug;
};
}; // end of logging clause
This configuration has no reverse localhost zone; localhost must be mapped in the /etc/hosts file.
A university department
The computer science department at the University of Colorado uses caching servers on each subnet; the caching servers forward to a list of slave servers. The slaves themselves forward to a master server that contacts the Internet on their behalf. Each forwarding server is configured to forward first. Below, we show all three configurations: the caching-only servers, the slave servers, and the master. All of the servers are running BIND 8.
The caching-only configuration is appropriate for a subnet that wants a local server but doesn