 | Chapter 8 |  |
| Chapter 8 | |
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 are 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.
Strictly speaking, name service is not necessary for computers to communicate. 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 nameserver configuration commands. This chapter provides sufficient information to show you how to configure BIND 4 software to run on your system. [1] But if you want to know more about why something is done, don't hesitate to refer to Chapter 3 and Appendix C.
[1] BIND 4 is the version of domain name software used on most UNIX systems. Another version of DNS software - BIND 8 - is also available. BIND 8 uses a different configuration file syntax. We use BIND 4 because it's the most widely used and comes with both Slackware 96 Linux and Solaris 2.5.1.
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 that are sent to the server. The DNS server software answers the resolvers' 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 nameserver (named)
Constructing the nameserver database files, called the zone files
The term zone is often used interchangeably with the word domain, but here we make a distinction between these terms. We use zone to refer to the domain 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 domain 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 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, primary servers, and secondary servers.
The resolver is the code that asks nameservers for domain information. On UNIX systems, it is implemented as a library, rather than a separate client program. Some systems, called resolver-only systems, use only the resolver; they don't run a nameserver. 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 primary nameserver is the authoritative source for all information about a specific domain. 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 server has authority. The primary server is a master server, because it can answer any query about its domain with full authority. [2]
[2] The terms master server and authoritative server are used interchangeably.
Configuring a primary server requires creating a complete set of configuration files: zone files for the regular domain and the reverse domain, the boot file, the cache file, and the loopback file. No other configuration requires creating this complete set of files.
A secondary server transfers a complete set of domain information from the primary server. The zone file is transferred from the primary server and stored on the secondary server as a local disk file. This transfer is aptly called a zone file transfer. A secondary server keeps a complete copy of all domain information, and can answer queries about that domain with authority. Therefore, a secondary server is also considered a master server.
Configuring a secondary server does not require creating local zone files, because the zone files are downloaded from the primary server. However, the other files (a boot file, a cache file, and a loopback file) are required.
A caching-only server runs the nameserver software, but keeps no nameserver database files. It learns the answer to every nameserver 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 nameservers use cached information in this manner, but a caching-only server depends on this technique for all of its nameserver information. It is not considered an authoritative (or master) 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 nameserver configuration, and apart from the resolver-only configuration, it is the easiest to configure.
A server may be 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 |