The Slave Server Configuration

Configuring a slave server is almost as simple as configuring a caching-only server. It uses the same three configuration files with only minor modifications to the named.conf file. Because of this, you can start with a caching-only configuration to test your system before you configure it as a slave server. Our sample slave server will be built by modifying the common caching-only configuration shown in Listing 4.4.

Assume that wren (172.16.5.1) is the master server for the foobirds.org domain and the 16.172.in-addr.arpa reverse domain, and that we want to configure falcon as a slave server for those domains. To accomplish this, we add two new zone statements to the basic named.conf file on falcon to create the configuration shown in Listing 4.9.

Listing 4.9: A DNS Slave Server Configuration

$ cat /etc/named.conf options {

directory "/var/named";

// a slave server configuration

type hint; file "named.ca";

zone "0.0.127.in-addr.arpa" { type master; file "named.local";

zone "foobirds.org" { type slave;

file "foobirds.hosts"; masters { 172.16.5.1; }; allow-updates { none; };

zone "16.172.in-addr.arpa" { type slave;

file "172.16.reverse"; masters { 172.16.5.1; }; allow-updates { none; };

The access control list and the allow-query option from Listing 4.4 have been removed from this configuration. Authoritative servers (the master and all official slaves) should accept queries from any source because they are advertised to the world through the domain's NS records. When you advertise a service, you should provide it.

The configuration file contains all of the zone statements that have already been discussed because all servers use a hints file and a loopback domain database file. The two new zone statements declare zones for the domains foobirds.org and 0.16.172.in-addr.arpa. The type clause in each of the new zone statements says that this is a slave server for the specified domains.

The file clause for a slave zone has a different purpose than those that you have seen before. In the previous examples, the file identified by the file clause was the source of the zone information. In this case, the file is the local storage for the zone information. The ultimate source for the information is the master server.

The masters clause identifies the master server. There can be more than one IP address provided in this clause, particularly if the master server is multihomed and thus has more than one IP address. In most configurations, only one address is used, which is the address of the master server for the specified zone.

The slave server downloads the entire zone file from the master server. This process is called a zone file transfer. When the file is downloaded, it is stored in the file identified by the file clause. Don't create or edit this file; it is created automatically by named. After the zone is downloaded, it loads directly from the local disk. The slave will not transfer the zone again until the master server updates the zone. How the slave knows when the zone has been updated is covered later in this chapter.

Configuring caching servers and slave servers doesn't seem very difficult, so what's the big deal about DNS configuration? The big deal is the master server, and that's what we tackle next.

Was this article helpful?

0 0

Post a comment