• Choose a category
• All
• Classic-Fiction

anchor.cs.colorado.edu.cs.colorado.edu.

you can be pretty sure that you forgot a trailing dot somewhere.

The masters statement lists the IP addresses of one or more machines from which the zone database can be obtained. We have said that only one machine can be the master for a zone, so why is it possible to list more than one address? Two reasons.

First, the master machine might have more than one network interface, and therefore more than one IP address. It’s possible for one interface to become unreachable (due to network or routing problems) while others are still accessible. Therefore, it’s a good practice to list all of the master server’s topologically distinct addresses.

Second, named really doesn’t care where the zone data comes from. It can pull the database just as easily from a slave server as from the master. You could use this feature to allow a well-connected slave server to serve as a sort of backup master, since the IP addresses will be tried in order until a working server is found. In theory, you can also set up a hierarchy of servers, with one master serving several second-level servers, which in turn serve many third-level servers.

We suggest that you list only bona fide master server addresses on the masters line.

Setting up the root hints

Another form of zone statement points named toward a file from which it can prime (preload) its cache with the names and addresses of the root name servers:

zone "." {

type hint;

file "path";

};

The “hints” are a set of DNS records that list servers for the root domain (“.”). They’re needed to give named a place to start searching for information about other sites’ domains. Without them, named would only know about the domains it actually serves and their subdomains.

The hints file is often called root.cache; it contains the response you would get if you queried a root server for the name server records in the domain “.”. We discuss how to set up a proper hints file starting on page 479.

BIND 9 has root server hints compiled into its code, so no configuration of the root zone is really needed. If you provide a hints file, however, BIND 9 will use it. We recommend that you do supply explicit hints; politics have entered the DNS arena, making root name servers and their IP addresses more volatile.

Setting up a forwarding zone

A zone of type forward overrides named’s global forwarding settings (described on page 421) for a particular domain:

zone "domain_name" {

type forward;

forward only | first;

forwarders { ip_addr; ip_addr; ... };

};

You might use a forward zone if your organization had a strategic working relationship with some other group or company and you wanted to funnel traffic directly to that company’s name servers, bypassing the standard query path. You could use such an arrangement to access name servers that were invisible to the outside world.

The key statement

The key statement defines a named encryption key to be used for authentication with a particular server. Background information about BIND’s support for cryptographic authentication is given in the Security issues section starting on page 460. Here, we just touch briefly on the mechanics of the process.

To build a key, you specify both the cryptographic algorithm that you want to use and a “shared secret,” represented as a base-64-encoded string:

key key-id {

algorithm string;

secret string;

};

As with access control lists, the key-id must be defined earlier in the named.conf file than it is first used. To associate the key with a particular server, just include key-id in the keys clause of that server’s server statement. The key is used both to verify requests from that server and to sign the responses to those requests.

The trusted-keys statement

The trusted-keys statement is for DNSSEC security, specified in RFC2065. Each entry is a 5-tuple that identifies the domain name, flags, protocol, algorithm, and key that are needed to talk securely to a name server for that domain. The format is:

trusted-keys {

domain