|
15.2. Delivering Names with DNSA second key network management tool is DNS. DNS servers fill two roles: enabling your local clients to convert names to IP addresses for local and remote computers, and enabling remote systems to find local computers that you choose (such as web or mail servers). One important question is whether you should even run a local DNS server; for many purposes, relying on outside servers makes a lot of sense. Sometimes, though, running a DNS server locally is very helpful. If you decide you want to run your own DNS server, you must be able to configure it. The basic DNS server configuration varies with the server software you select. BIND is the most popular Linux DNS server, and so it's described in this chapter. Once the basic configuration is set, you must create files that describe the computers on your networktheir hostnames, IP addresses, and related characteristics. Finally, you must be able to tell clients to use the DNS servers you've configured. 15.2.1. Principles of DNSDNS is, essentially, a global database of computer names. The huge size of the DNS database presents many challenges, including maintenance of the database and providing storage space for it. Both challenges are overcome by the fact that DNS is a distributed database; no one computer holds all the data in the DNS database. Instead, the DNS namespace is arranged hierarchically. At the top of the hierarchy are the top-level domains (TLDs), which appear at the end of a DNS hostname. Common examples include .com, .edu, and .net. These three TLDs are all examples of generic TLDs (gTLDs), which are (theoretically) not tied to specific nations. Another type of TLD is the country code TLD (ccTLD), which uses a two-digit country code as the TLD, such as .us for the United States or .ru for Russia. Below the TLDs are the domain names that are so common, such as oreilly.com for O'Reilly Media or upenn.edu for the University of Pennsylvania. These domains can be further subdivided, such as cis.upenn.edu for the Computer and Information Science department at the University of Pennsylvania. At some point, individual computers can be specified, as in www.oreilly.com for the O'Reilly web server. The beauty of DNS's distributed nature is that it ties into this hierarchy. At each level of the hierarchy, a single DNS server can reasonably hold data on all the domains or subdomains at that level. At the very top of this hierarchy, a set of computers known as the root servers maintain information on the TLDs. Each root server can field queries concerning TLDs; most importantly, the root servers can tell a client where to find DNS servers for the .com, .ru, and other TLDs. The client can then contact a TLD's DNS server for information on a specific domain, such as oreilly.com; the result is the address of the oreilly.com DNS servers. With this information in hand, the client can ask about a specific computer, such as www.oreilly.com. The distributed DNS system therefore enables lookups in a huge address space relatively quickly. Although multiple queries may be needed, each one finishes rather rapidly. DNS also includes certain time-saving features. For instance, rather than have users' workstations perform the full recursive lookup, in which a name is queried starting with the root servers, a network can host a DNS server that does this job and caches the results. Thus, if two users on a network look up www.oreilly.com in quick succession, the local DNS server needn't perform a full recursive lookup for the second query; it simply retrieves the result of the original lookup from its cache and delivers that result. This characteristic is also a key to understanding the two main roles that a DNS server can play on your network:
This chapter focuses on the first type of DNS configurationthat which is most useful to local computers. The principles described here also form the foundation for making changes that are accessible to the outside world, though.
Running a DNS server for the benefit of your local computers is most useful if your ISP doesn't provide one or if you want to deliver information that's unique to your private network. For instance, you might have a subnet behind a firewall that holds file servers, print servers, and pull mail servers to be used by other computers behind the firewall. Entering information on these systems in a globally accessible DNS server is unnecessary and can even give potential attackers information about your network, so running a DNS server behind the firewall can be a good way to provide local name resolution. This server can also handle full recursive lookups for the benefit of other local computers.
15.2.2. Basic Name Server ConfigurationRunning a name server involves two basic configuration tasks: setting up the name server itself (that is, the options it uses to control where it stores additional configuration files, how it should respond, and so on) and setting up the domains it handles. This section describes the first of these tasks, using the BIND software as an example. (If you use another server, such as djbdns, you need to read its documentation.) The second task is described in the next section. The Berkeley Internet Name Domain (BIND) is distributed by the ISC (http://www.isc.org), which also distributes the most common Linux DHCP server. As with ISC's DHCP server, BIND is available with all major distributions, except for some very desktop-oriented ones; thus, you shouldn't need to download it from the ISC web site unless you have a specific reason to avoid your distribution's BIND package. Typically, the package name is bind. Although the official name for this server package is BIND, the executable filename is named, and BIND configuration files are named after thisnamely, the main configuration file is /etc/named.conf. For a simple configuration, this file contains two broad classes of entries:
Example 15-2 shows a simple but usable /etc/named.conf file. This file defines the basic settings for a BIND server handling the example.com domain. It includes an options section and four zone sections, which are described in more detail shortly. A DNS server for a network with multiple subnets or domains is likely to have additional zone sections. Example 15-2. Sample /etc/named.conf fileoptions { directory "/var/named"; listen-on{ 192.168.1.1; 172.24.21.1; }; forwarders { 10.29.102.7; 10.65.201.7; }; forward first; }; zone "." { type hint; file "named.ca"; }; zone "example.com" { type master; file "named.example.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 general format of the /etc/named.conf file is similar to that of the ISC DHCP server. Most lines set individual options and end in semicolons (;). Other lines, though, begin or end blocks of options. The line that begins such a block ends in an open curly brace ({), and the line ending such a block ends in a close curly brace and a semicolon (};). The options section in Example 15-2 sets several important global features of the server:
Many other directives can be placed within the options section, but the ones described here should be enough for many small configurations. Consult the documentation that came with BIND, or a book on the server, such as O'Reilly's DNS and BIND, for more information on these options. If you want BIND to deliver information on your local network, the zone definitions are just as important as the options section. Each zone definition begins with the zone keyword followed by the name of the zone. Chances are your named.conf file will have three broad classes of zone definitions:
Once you've configured the basics in /etc/named.conf, you might be tempted to restart the named server. You can do so in the usual way, such as by using a SysV startup script, however, you should probably wait until you've created appropriate domain configuration files, as described next. 15.2.3. Setting Up a DomainConfiguring the basics of the server's options is just the start of the process. In day-to-day operation, you're more likely to need to modify your zone definitions, which are stored in files in the directory specified with the directory keyword in the options section of the /etc/named.conf file. Each zone has its own configuration file, which defines features of the zone as a whole and creates mappings of hostnames to IP addresses for each member of the zone. Each type of zone definition in named.conf has its own variant style of zone definition file. The most fundamental of these is the root zone definition. Chances are your BIND configuration includes a default configuration that will work. Typically, the filename is named.ca or db.cache. If this file isn't present, or if it's very old, you should try to obtain a more up-to-date version. You can find the latest copy from ftp://ftp.rs.internic.net/domain/db.cache. Copy this file to the directory specified in your named.conf file, and name it as specified by the file option in that file's root zone definition (zone "."). Additional zone files are the forward and reverse zone files. 15.2.3.1 Configuring forward zone filesThe second type of zone definition is for forward lookupsthose that use an ordinary domain name in the zone line of named.conf. Use whatever filename you specify in named.conf for the file. Typically, this name is related to your domain's name, such as named.example.com for the example.com domain. Example 15-3 shows a sample forward lookup zone configuration file. Example 15-3. A sample forward zone definition file$ORIGIN . $TTL 604800 ; 1 week example.com IN SOA maize.example.com. linnaeus.example.com. ( 2004102609 ; serial 28800 ; refresh (8 hours) 14400 ; retry (4 hours) 3600000 ; expire (5 weeks 6 days 16 hours) 86400 ; minimum TTL (1 day) ) $ORIGIN example.com. maize IN A 192.168.1.1 gingko IN A 192.168.1.2 mandragora IN A 192.168.1.3 mandrake IN CNAME mandragora mail IN A 10.23.186.78 www IN A 172.24.217.102 @ IN NS maize.example.com. @ IN MX 10 mail.example.com. The zone file begins with two lines that set some global parameters. The $ORIGIN . line should be present in your zone files unchanged. The $TTL 604800 line sets a default time-to-live (TTL) value, which tells other servers how long, in seconds, they may cache entries obtained from your server. You may increase or decrease this value as you see fit. The lines beginning with example.com and ending with a single close parenthesis ")" define the start of authority (SOA) record for this zone. This entry sets several important overall features for the zone:
Following the SOA record is a line that explicitly sets the $ORIGIN to your domain, including its trailing dotexample.com. in this case. Subsequent lines are similar in form to the SOA line, but they're simpler; most take the following form: hostname IN code address The hostname is the hostname in question, without a domain component. Some entries enable you to specify an at sign (@) as the hostname. This symbol stands in for the domain name and is used by certain code types, as described shortly. The IN component is invariant in these entries, at least as far as described in this chapter. The code is a code that stands for the entry type and is described in more detail shortly. Finally, the address is the address to associate with the hostname. In many cases, this is an IP address; but for some code types, it can be a hostnameeither a hostname without a domain, which is interpreted as a hostname in the current domain or a hostname with domain component and trailing dot. The MX code is unique in that it includes a number before the address, as described shortly. In defining a domain, you're likely to include several different types of code:
15.2.3.2 Configuring reverse zone filesIn some cases, you need to configure only forward lookups. For instance, your ISP might own your network block and so handle the reverse lookups, or you might simply not care about reverse lookups. (Some programs, though, perform reverse lookups and compare them to the forward lookups. If the two don't match, the programs terminate the connection or otherwise cause headaches. Thus, working reverse lookups can be more than just a convenience.) If you're in control of your network block, including if you're running in a private reserved address space, you can configure a reverse lookup zone. To do so, you must first specify a reverse lookup zone in the /etc/named.conf file, as described earlier, in Section 15.2.2. You can then create a reverse lookup file in your zone file directory. This file is likely to be named after the zone, e.g., named.192.168.1. Example 15-4 shows an example of such a file. Example 15-4. A sample reverse zone definition file$TTL 1W 1.168.192.in-addr.arpa. IN SOA maize.example.com. linnaeus.example.com. ( 2004102609 ; serial 28800 ; refresh 14400 ; retry 3600000 ; expire 86400 ; default_ttl ) 1 IN PTR maize.example.com. 2.1.168.192.in-addr.arpa. IN PTR gingko.example.com. 3.1.168.192.in-addr.arpa. IN PTR mandragora.example.com. 1.168.192.in-addr.arpa. IN NS maize.example.com. The reverse lookup file is very similar to the forward lookup file. Like the forward lookup file, it includes a $TTL directive. (Example 15-4 shows an alternative way of specifying the time, though, by including a one-letter abbreviation for the time unit1W meaning one week.) This file also contains an SOA record, which takes the same form as the equivalent record in the forward zone definition file; the main difference is in the name of the domain. (You can use different specifics, such as refresh times or network administrator email address if you like, though.) The bulk of the post-SOA entries in a reverse lookup file are PTR records, which tie an IP address (in the form of its reversed in-addr.arpa pseudo-hostname) to conventional hostnames. As with forward lookup files, you can abbreviate hostnames by omitting the domain portion of the name. In the case of reverse lookup files, though, the domain portion of the name is the reversed network portion of the address and in-addr.arpa. Thus, the reverse lookup for the 192.168.1.1 address in Example 15-4 is 1, referring to the final byte of the IP address. Example 15-4 doesn't use this convention for the remaining addresses. The looked-up names (maize.example.com., gingko.example.com., and so on in Example 15-4) may not be abbreviated by omitting their domain portions. You must also include the trailing dot after each of these names. In addition to SOA and PTR records, reverse lookup zone files typically include one or more NS records, which point to the DNS servers that handle the network block. These might or might not be the same servers that handle forward lookups for the computers in that network block. Other record types, such as A, CNAME, and MX, are uncommon in reverse lookup files. 15.2.3.3 Running the serverOnce you've set up your domain, you can start the server. Typically, this is done via a SysV startup script; typing /etc/init.d/named start or something similar usually does the job. To run the server permanently, you can use chkconfig or a similar tool to add the server to your default runlevel, or do the job manually by creating appropriate symbolic links yourself. Consult distribution-specific documentation if you need help with this job. Once the server has started, you may want to check the last few lines of your log files to see if the server has reported any problems. Typing tail /var/log/messages can do this.
You can test your server's operation using the host command on the server or any other computer that has this tool. Type host name server to look up name using the specified server. If the computer pauses for several seconds and responds connection timed out, chances are the server has crashed on startup or you've specified the wrong server. (You may need to specify server as an IP address if the computer isn't configured to use that system for name resolution by default.) Other error messages typically denote problems with your DNS configuration; check your logfiles for clues. Be sure to test both forward and reverse DNS lookups. 15.2.4. Pointing Clients at the Name ServerClient configuration is, of course, critically important to DNS operation. If you want local workstations and servers to use your DNS server for name resolution, you must tell them to do so. If you use DHCP to assign IP addresses to these computers, the simplest way to configure them to use your DNS server is to adjust your DHCP configuration using the option domain-name-servers line in your DHCP configuration file, as described earlier, in the section Section 15.1.4.1. Once configured in this way, a DHCP server can deliver DNS server information to Windows, Linux, Mac OS, and other clients that use DHCP. If you want to configure some or all of your computers using static IP addresses without using DHCP, you must configure these computers to use your DNS servers manually. Precisely how you do so varies from one OS to another, but most provide GUI tools that enable you to enter the DNS server addresses manually. Earlier, the Section 15.1.5 described how to configure Windows XP to use DHCP. Part of this process provided an opportunity to tell Windows to use the DNS servers provided by the DHCP server or to use servers you specify. In particular, Figure 15-1 shows the relevant dialog box. Click "Use the following DNS server addresses," and enter up to two DNS server addresses to have Windows use them instead of those provided via DHCP or if you don't use DHCP at all. Similar tools exist in other versions of Windows and in other OSs. Although you can enter DNS server addresses using GUI tools in most Linux distributions, Linux supports another method: the /etc/resolv.conf file specifies DNS servers and the domains that Linux should attempt to search. This file is likely to be quite short: domain example.com search example.com,pangaea.edu nameserver 192.168.1.1 nameserver 10.29.102.7 Each line has a specific purpose:
Whether the DNS client runs Linux, Windows, or some other OS, a DNS lookup normally uses a domain search list, even if the user specified a hostname with a domain. For instance, if you do a lookup on mandragora.example.com from within the example.com domain, the computer first tries a lookup on mandragora.example.com.example.com. If additional domains are in the search paths, similar lookups are performed on them, as in mandragora.example.com.pangaea.edu. When these lookups fail, the name resolver tries the lookup without appending any item from the search path. The assumption is that the user has entered a relative hostname without a domain component. You can block this initial, and probably erroneous, lookup by appending a dot, e.g., typing mandragora.example.com. rather than mandragora.example.com when entering the hostname. This trick works with most programs and protocols, but it might confuse some. In most cases, it's unnecessary; the extra lookup that fails is unlikely to take very long at all, so it does no real harm. |
|