Core DNS Configuration

DNS configuration may be thought of as consisting of two tasks : Configuring the DNS server itself (which is called named in the case of BIND), and administering your domain. This section covers the most common options for the first task, and the next section, "Domain Administration Options," covers domain administration. (Subsequent sections cover a couple of special configurations that may be of interest to you ”running a local DNS server for its cache and integrating BIND with a DHCP server.) Basic DNS configuration requires that you set basic configuration options, that you locate other DNS servers ( especially the root servers), and that you tell the server about the zones you intend to administer. All but the smallest domains require a secondary name server. In theory, you could simply copy the configuration files to exactly duplicate the configuration, but it's usually better to set up the secondary server to automatically mirror the first one's files.

The BIND Configuration File

Most basic BIND configuration options appear in the main BIND configuration file, named.conf . This file usually resides in /etc , but some distributions' BIND packages don't provide a default file in that location. You can usually find a sample file somewhere in the BIND documentation directory (often /usr/share/doc/bind- version ). Listing 18.1 shows a short but complete named.conf file.

Listing 18.1 A sample named.conf file
 options {         directory "/var/named/";         auth-nxdomain yes;         forwarders {       ;       ;         };         forward first;  }; zone "." {         type hint;         file ""; }; zone "" {         type master;         file ""; }; zone ""{         type master;         file "named.192.168.1"; }; zone "" {         type master;         file "named.local"; }; 

The named.conf file is broken up into sections. In the case of Listing 18.1, these are options and several zone sections. The options section sets global options such as the directory in which zone configuration files are stored. The zone sections define specific zones ”that is, domains or other logical groupings of hostnames or IP addresses. Most lines in named.conf end in semicolons ( ; ). This is a requirement of the file format, so you should be careful to follow it lest BIND become confused . Much of what named.conf does is to point BIND to files that provide more information about specific zones. These files reside in /var/named (or whatever location you specify with the directory option).

The following sections describe the contents of named.conf in more detail.

Locating Other Name Servers

One of the first tasks you must perform when installing a DNS server is to obtain a list of root name servers. There are several ways to obtain this list. Possibilities include:

  • The file may ship with your BIND package, probably under the name or db.cache under the /var/named directory. This file might be outdated , though, so you may want to check for a more up-to-date file using either of the following two methods .

  • You can obtain the file via FTP from under the filename .

  • If your system has the dig program installed, you can type dig @a. . ns > to retrieve the file and call it .

The second and third options both require that your system have access to a working DNS server. If your network has no such server, you can try obtaining the file on a computer attached to another network, or temporarily set your future DNS computer to use another system for name resolution, as described in Chapter 2, TCP/IP Network Configuration.

When you've retrieved the root server list, copy it to the /var/named directory. You must also ensure that your /etc/named.conf file includes a reference to the root server list. The root server list is specified in the zone "." section, using the file option, as shown in Listing 18.1. Be sure the filename you use for the root zone file matches the one listed in named.conf . (Technically, hostnames all end in periods, so the root zone is indicated by a bare period.)

Setting Up a Forwarding Server

The default function of BIND is to perform lookups in one of three ways, in sequence:

  1. If BIND is configured as the authoritative server for an address, the server responds with the address set in its configuration files.

  2. If the request is for an address in the program's cache, the server returns that address. This feature improves performance, as noted earlier, and reduces network traffic.

  3. If the requested address isn't in BIND's cache, the server queries a root name server, and other name servers, as described earlier. This recursive lookup usually takes just a few seconds at worst, but it is slower than a cached lookup.

BIND supports a fourth option, though: It can query a DNS server and let that server do the tedious recursive lookup. When so configured, BIND tries this option after checking its local cache but before performing a full recursive lookup. The idea is that a name server running on a small network that has access to a larger, but still somewhat local, name server may produce quicker lookups if it can rely upon the cache and faster network connections of that larger DNS server. For instance, if you operate a home or small office network that's tied to the Internet via a dial-up or satellite-based connection, you might want to configure the server to forward DNS requests to your ISP's DNS server. Connections such as dial-up and satellite broadband have high latencies, so the multiple queries of a full recursive lookup can take several seconds to perform.

Why not simply tell your local computers to use your ISP's server directly, though? Perhaps you want to run your own local DNS server to handle your local systems' names , or perhaps you want the benefit of a cache that's even closer to your systems than is your ISP's server. Also, a few ISP's DNS servers are unreliable, so having your own configured as a fallback can improve the reliability of your network connection.

In any event, a forwarding configuration like this is created with the forwarders and forward first options, as shown in Listing 18.1. The forwarders option allows you to specify the IP addresses of one or more DNS servers that yours is to query for information before trying to perform a recursive lookup. The forward option can take one of two values ” only or first . If you specify forward only , BIND will rely exclusively upon the specified remote DNS server; BIND will not perform a recursive search of its own. By contrast, forward first causes BIND to attempt a lookup through the specified remote DNS servers, but if that lookup fails (say, because the remote DNS servers aren't responding), BIND proceeds with a normal recursive lookup. In both cases, BIND still relies upon its own zone configuration if it's been told it's authoritative for a zone, as described shortly.

Setting Up Zones

When you set up BIND, you must tell it how to handle requests for specific domains, subdomains, and IP address ranges. These different groups of names and addresses are referred to as zones. A zone may be either a domain or subdomain (as in the zone in Listing 18.1) or a range of IP addresses (which are specified by zone names ending in ). A small DNS server will set up a handful of zones:

  • The root zone ” A zone identified by a single period ( . ) refers to the root of the name space. This zone definition uses the type hint option to tell BIND to defer to the name servers listed in the file specified by the file option, as described earlier.

  • Your local domain ” Unless you're running a caching-only name server, you'll want to configure BIND to handle a zone that corresponds to your domain or subdomain. Listing 18.1's zone is an example of this configuration.

  • Reverse DNS zones ” Although DNS is most commonly used to look up an IP address from a hostname, the reverse lookup is also possible. This is known as a reverse DNS lookup, and it's handled by zone names that end in . Preceding this string in the zone name is a partial IP address, in reverse order. For instance, the entry for the network is called , as shown in Listing 18.1.

A basic zone configuration specifies the zone's type and lists a configuration file that provides additional information about the zone. Zone types may be any of the following:

  • master ” A master server is one that contains the original authoritative control file for a zone. If you're configuring a DNS server for a small network, you'll probably configure its local domain's zones as masters. Listing 18.1 illustrates this approach.

  • slave ” A slave server obtains information on a zone from another DNS server. The slave is still considered an authoritative source for that zone, though. The next section, "Configuring a Slave Server," covers these options in more detail. A single BIND server may function as a master for some zones and as a slave for others. It's usually simplest to set up one master and a matching slave, though.

  • stub ” This configuration is much like a slave configuration, except that the stub server copies only NS records ”that is, name server specifications. You'd use this option if you want to configure a separate DNS server for a subdomain. For instance, if has a subdomain called , and if you want to run a separate DNS server for , you could include a zone in the BIND configuration and give it a stub type that points to the DNS server. Alternatively, you could use one DNS server to handle the entire domain, including the subdomain. This would require no special zone entry for .

  • forward ” Like a forward option in the options section, a forward zone type tells BIND to pass on requests for information on a zone to another DNS server. Essentially, BIND issues its own DNS request to the specified servers, then responds with the results of this query. To be effective, you must include a forwarders option to tell BIND to what remote DNS servers to forward requests.

  • hint ” This zone type is unique to the root name server specification. You use it to tell the system where to find a list of root name servers. BIND should then try to update that list from one of the root name servers itself.

A simple configuration, such as that shown in Listing 18.1, can include just one hint zone and a handful of master zones. More complex configurations may include all of the preceding zone types.

Configuring a Slave Server

If you're running your own DNS servers for a registered domain, you must configure two DNS servers. This is normally handled by making one server a slave of the other. The slave server stores its zone information in separate files, just like the master server. The main difference is that the slave server automatically retrieves the zone files from its master server. You tell the slave how to do this by changing the zone configuration in /etc/named.conf . For instance, suppose you want to set up a server to act as a slave to the one configured through Listing 18.1. The zone configuration for the domain on the slave might resemble the following:

 zone "" {         type slave;         file "";         masters {; } }; 

This tells the slave to obtain its configuration file for from the DNS server at If the slave is to be a slave for multiple domains, you should include several such definitions. You can include several DNS servers in the masters list, if you have more than two DNS servers for the domain; separate the IP addresses with semicolons ( ; ). (In fact, one slave can synchronize itself from another slave.) If the server is a slave for several zones, each zone can synchronize against a different master. You might use this feature if you're administering several domains, each of which should have its own master, but for which a single shared slave is acceptable.

Remember to configure slave zones for both forward lookups (as in the zone) and reverse lookups (as in the 1.168.192. zone in Listing 18.1). You should not configure a slave DNS server to use slave zones for the root name servers or for the localhost reverse lookups ( in Listing 18.1).

When you start a server after configuring it as a slave, you should see the zone files specified in the zone options appear. If you don't, check the log files on both the master and slave systems for clues to what went wrong. One possibility is that the master might be configured to refuse zone transfers. This may be done as a security measure to keep outsiders from retrieving information on all your domain's local computers. If you want to restrict zone transfers on either your master or your slave DNS servers, you can do so with the allow-transfer option, which can go in either the options section or a specific zone section. For instance, you might use the following settings to restrict transfers to computers on the network and to

 allow-transfer {         192.168.1/24;; }; 

Advanced Linux Networking
Advanced Linux Networking
ISBN: 0201774232
EAN: 2147483647
Year: 2002
Pages: 203

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: