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 FileMost 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 fileoptions { directory "/var/named/"; auth-nxdomain yes; forwarders { 10.232.7.98; 10.232.45.1; }; forward first; }; zone "." { type hint; file "named.ca"; }; zone "threeroomco.com" { type master; file "named.threeroomco.com"; }; zone "1.168.192.in-addr.arpa"{ type master; file "named.192.168.1"; }; zone "0.0.127.in-addr.arpa" { 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 ServersOne 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 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 ServerThe default function of BIND is to perform lookups in one of three ways, in sequence:
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 ZonesWhen 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 threeroomco.com zone in Listing 18.1) or a range of IP addresses (which are specified by zone names ending in in-addr.arpa ). A small DNS server will set up a handful of zones:
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:
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 ServerIf 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 threeroomco.com domain on the slave might resemble the following: zone "threeroomco.com" { type slave; file "named.threeroomco.com"; masters { 192.168.1.50; } }; This tells the slave to obtain its configuration file for threeroomco.com from the DNS server at 192.168.1.50. 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 threeroomco.com zone) and reverse lookups (as in the 1.168.192. in-addr.arpa 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 ( 0.0.127.in-addr.arpa 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 192.168.1.0/24 network and to 172.19.98.23: allow-transfer { 192.168.1/24; 172.19.98.23; }; |