Chapter 14. Berkeley Internet Name Domain (BIND)

Today, the Internet and almost all local networks depend upon a working and reliable Domain Name Service (DNS), which is used to resolve names of systems into IP addresses and vice versa.

In order to facilitate DNS on your network, a nameserver is required to translate these names into the IP addresses necessary to make the connection. In addition, a nameserver can translate IP addresses back into a system's name, commonly called a reverse lookup.

This chapter discusses BIND, the structure of its configuration files, and how it may be locally or remotely administered.

For BIND configuration instructions using the GUI BIND Configuration Tool, please see Official Red Hat Linux Customization Guide. Note that, if you are using the BIND Configuration Tool, you should not manually edit your BIND configuration files, due to the fact that any manual changes will be overwritten by the BIND Configuration Tool.

Introduction to DNS and BIND

Systems using IP networks must know the IP address of a remote machine in order to connect to it. However, most users prefer to use names of machines, such as hostname or a fully qualified domain name (FQDN), to specify a system when connecting to it. In addition, many programs utilize domain names in their configuration files when referring to a remote system, in order to allow IP addresses to be changed without modifying the system's name, among other reasons. The service that facilitates this is caused DNS, and it is normally implemented using centralized servers that are authoritative for some domains and refer to other DNS servers for information they do not already know.

DNS is made possible through the use of nameserver daemons that perform the IP/name translation. A client application will request information from the nameserver, usually connecting to it on the server's port 53. The nameserver will attempt to resolve the FQDN based on its resolver library, which may contain authoritative information about the host requested or cached data about that name from an earlier query. If the nameserver does not already have the answer in its resolver library, it will turn to other nameservers, called root nameservers, to determine which nameservers are authoritative for the FQDN in question. Then, with that information, it will query the authoritative nameservers for that name to determine the IP address. If performing a reverse lookup, the same procedure is used, except the query is made with an unknown IP address rather than a name.

Zones

On the Internet, the FQDN of a host can be broken down into different sections, and these sections are organized in a hierarchy much like a tree, with a main trunk, primary branches, secondary branches, and so forth. Consider the following FQDN:

bill.sales.domain.com

Figure 14-1. Example of a fully qualified domain name

When looking at how a FQDN is resolved to find the IP address that relates to a particular system, you must read the name from right to left, with each level of the hierarchy divided by dots (.). In this example, the com defines the top level domain for this FQDN. The domain name is a sub-domain under com, with sales as a sub-domain under domain. The name furthest left in a FQDN is the hostname, identifying a particular machine.

Except for the hostname, every section is a called a zone, which defines a particular namespace. A namespace controls the naming of the sub-domains to its left. While this example only contains two sub-domains, a FQDN must contain at least one sub-domain but may include many more, depending upon the namespace organization in use.

Zones are defined on authoritative nameservers through the use of zone files, which describe the namespace of that zone, the mail servers to be used for a particular domain or sub-domain, and much more. Zone files are stored on primary nameservers (also called master nameservers), which are truly authoritative and where changes are made to the files, and secondary nameservers (also called slave nameservers), which receive their zone files from the primary nameservers. Any nameserver can be a primary and secondary nameserver for different zones at the same time, and they may also be considered authoritative for multiple zones. It all depends on the nameserver's particular configuration..

Types of Nameservers

There are four primary nameserver configuration types:

master — Stores original and authoritative zone records for a certain namespace, answering questions from other nameservers searching for answers concerning that namespace.
slave — Also answers queries from other nameservers concerning namespaces for which it is considered an authority. However, slave nameservers get their namespace information from master nameservers via a zone transfer, where the slave sends the master a NOTIFY request for a particular zone and the master responds with the information, if the slave is authorized to receive the transfer.
caching-only — Offers name to IP resolution services but is not authoritative for any zones. Answers for all resolutions are usually cached in a database stored in memory for a fixed period of time, usually specified by the retrieved zone record, for quicker resolution for other DNS clients after the first resolution.
forwarding — Forwards requests to a specific list of nameservers to be resolved. If none of the specified nameservers can perform the resolution, the process stops and the resolution fails.

A nameserver may be one or more of these types. For example, a nameserver can be a master for some zones, a slave for others, and only offer forwarding resolution.

BIND as a Nameserver

Red Hat Linux includes BIND, which is a very popular, powerful, open source nameserver. BIND uses the named daemon to provide its name resolution services. All configuration information for BIND is kept in the /etc/named.conf file and its zone files are in the /var/named directory. The structure and options for these various types of files can be found in the section called BIND Configuration Files.

BIND version 9 includes a utility called rndc to allow the administration of the running named daemon. More information about rndc can be found in the section called Using rndc.