Chapter 16. 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 instructions on configuring BIND using the graphical Bind Configuration Tool (redhat-config-bind), please see the chapter called BIND Configuration in the Official Red Hat Linux Customization Guide.

WarningWarning
 

If you use the Bind Configuration Tool, you should not manually edit any BIND configuration files because all changes will be overwritten the next time you use 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 the name of a machine, called a hostname or a fully qualified domain name (FQDN), when connecting to it.

Use of fully qualified domain names also have advantages for system administrators. They allow administrators to flexibility in changing the IP addresses for individual machines without effecting name-based queries to the machines. Conversely, administrators can shuffle which machines handle a name-based query in a way transparent to the user.

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 other domains.

DNS under Linux is made possible through the use of a nameserver daemon that performs the IP/hostname 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

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 how the namespace is organized.

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 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 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 name resolution services.

BIND version 9 also includes a utility called /usr/sbin/rndc which allows the administration of the running named daemon. More information about rndc can be found in the Section called Using rndc.