 |  |
| |
Congratulations! You have installed TCP/IP in the kernel, configured the network interface, and configured routing. At this point, you have completed all of the configuration tasks required to run TCP/IP on a Unix system. While none of the remaining tasks is required for TCP/IP software to operate, they are necessary for making the network more friendly and useful. In the next two chapters, we look at how to configure basic TCP/IP network services. Perhaps the most important of these is name service.
It is, as the name implies, a service -- specifically, a service intended to make the network more user-friendly. Computers are perfectly happy with IP addresses, but people prefer names. The importance of name service is indicated by the amount of coverage it has in this book. Chapter 3, "Network Services" discusses why name service is needed; this chapter covers how it is configured; and Appendix C, "A named Reference" covers the details of the name server configuration commands. This chapter provides sufficient information to show you how to configure the BIND software to run on your system.[82] But if you want to know more about why something is done or details on how to do it, don't hesitate to refer to Chapter 3, "Network Services" and Appendix C, "A named Reference".
[82]BIND 8 is the version of domain name software that comes with most versions of Linux and with Solaris 8. A newer version of DNS software -- BIND 9 -- is also available. BIND 8 and BIND 9 use essentially the same configuration file syntax. The examples presented here should work with both BIND 8 and BIND 9.
In Unix, DNS is implemented by the Berkeley Internet Name Domain (BIND) software. BIND is a client/server software system. The client side of BIND is called the resolver. It generates the queries for domain name information and sends them to the server. The DNS server software answers the resolver's queries. The server side of BIND is a daemon called named (pronounced "name" "d").
This chapter covers three basic BIND configuration tasks:
Configuring the BIND resolver
Configuring the BIND name server (named)
Constructing the name server database files, called the zone files
A zone is a piece of the domain namespace over which a name server holds authority. A zone cannot contain a domain that is delegated to another server. Here we use "zone" to refer to the DNS database file, while the term "domain" is used in more general contexts. In this book, a domain is part of the domain hierarchy identified by a domain name. A zone is a collection of domain information contained in a DNS database file. The file that contains the domain information is called a zone file.
RFC 1033, the Domain Administrators Operations Guide, defines the basic set of standard records used to construct zone files. Many RFCs propose new DNS records that are not widely implemented. In this chapter and in Appendix C, "A named Reference", we stick to the basic resource records that you are most likely to use. We'll use these records to construct the zone files used in this chapter. But how, or even if, you need to construct zone files on your system is controlled by the type of BIND configuration you decide to use.
BIND configurations are described by the type of service the software is configured to provide. The four levels of service that can be defined in a BIND configuration are resolver-only systems, caching-only servers, master servers, and slave servers.
The resolver is the code that asks name servers for domain information. On Unix systems, it is implemented as a library rather than as a separate client program. Some systems, called resolver-only systems, use only the resolver; they don't run a name server. Resolver-only systems are very easy to configure: you just need to set up the /etc/resolv.conf file.
The three other BIND configurations all require that the local system run the named server software. They are:
The master name server is the authoritative source for all information about a specific zone. It loads the domain information from a locally maintained disk file that is built by the domain administrator. This file (the zone file) contains the most accurate information about a piece of the domain hierarchy over which this name server has authority. The master server is an authoritative server because it can answer any query about its zone with full authority.
Configuring a master server requires creating a complete set of configuration files: zone files for the forward-mapping zone and the reverse-mapping zone, the conf file, the root hints file, and the loopback file. No other configuration requires creating this complete set of files.
A slave server transfers a complete set of zone information from the master server. The zone data is transferred from the master server and stored on the slave server as a local disk file. This transfer is aptly called a zone transfer. A slave server keeps a complete copy of all zone information and can answer queries about that zone with authority. Therefore, a slave server is also considered an authoritative server.
Configuring a slave server does not require creating local zone files because the zone files are downloaded from the master server. However, other files (a boot file, a cache file, and a loopback file) are required.
A caching-only server runs the name server software but keeps no zone files. It learns the answer to every name server query from some remote server. Once it learns an answer, the server caches the answer and uses it to answer future queries for the same information. All name servers use cached information in this manner, but a caching-only server depends on this technique for all of its name server information. It is not considered an authoritative server because all of the information it provides is secondhand. Only a boot file and a cache file are required for a caching-only configuration, but the most common configuration also includes a loopback file. This is probably the most common name server configuration, and apart from the resolver-only configuration, it is the easiest to configure.
A name server may use any one of these configurations or, as is often the case, it may combine elements of more than one type of configuration. However, all systems run the resolver, so let's begin by examining the configuration of the client side of the DNS software.
|  | |
| 7.8. Summary |  | 8.2. Configuring the Resolver |
Copyright © 2002 O'Reilly & Associates. All rights reserved.