Product SiteDocumentation Site

Chapter 10. The BIND DNS Server

10.1. Introduction to DNS
10.1.1. Nameserver Zones
10.1.2. Nameserver Types
10.1.3. BIND as a Nameserver
10.2. Configuring the named Service
10.2.1. Common Statement Types
10.2.2. Other Statement Types
10.2.3. Comment Tags
10.3. Editing Zone Files
10.3.1. Common Directives
10.3.2. Common Resource Records
10.3.3. Comment Tags
10.3.4. Example Usage
10.4. Using the rndc Utility
10.4.1. Configuring the Utility
10.4.2. Checking the Service Status
10.4.3. Reloading the Configuration and Zones
10.4.4. Updating Zone Keys
10.4.5. Enabling the DNSSEC Validation
10.4.6. Enabling the Query Logging
10.5. Using the dig Utility
10.5.1. Looking Up a Nameserver
10.5.2. Looking Up an IP Address
10.5.3. Looking Up a Hostname
10.6. Advanced Features of BIND
10.6.1. Multiple Views
10.6.2. Incremental Zone Transfers (IXFR)
10.6.3. Transaction SIGnatures (TSIG)
10.6.4. DNS Security Extensions (DNSSEC)
10.6.5. Internet Protocol version 6 (IPv6)
10.7. Common Mistakes to Avoid
10.8. Additional Resources
10.8.1. Installed Documentation
10.8.2. Useful Websites
10.8.3. Related Books
DNS (Domain Name System), also known as a nameserver, is a network system that associates hostnames with their respective IP addresses. For users, this has the advantage that they can refer to machines on the network by names that are usually easier to remember than the numerical network addresses. For system administrators, using the nameserver allows them to change the IP address for a host without ever affecting the name-based queries, or to decide which machines handle these queries.
This chapter covers BIND (Berkeley Internet Name Domain), the DNS server included in Red Hat Enterprise Linux. It focuses on the structure of its configuration files, and describes how to administer it both locally and remotely.

10.1. Introduction to DNS

DNS is usually implemented using one or more centralized servers that are authoritative for certain domains. When a client host requests information from a nameserver, it usually connects to port 53. The nameserver then attempts to resolve the name requested. If it does not have an authoritative answer, or does not already have the answer cached from an earlier query, it queries other nameservers, called root nameservers, to determine which nameservers are authoritative for the name in question, and then queries them to get the requested name.

10.1.1. Nameserver Zones

In a DNS server such as BIND, all information is stored in basic data elements called resource records (RR). The resource record is usually a fully qualified domain name (FQDN) of a host, and is broken down into multiple sections organized into a tree-like hierarchy. This hierarchy consists of a main trunk, primary branches, secondary branches, and so on.
Example 10.1. A simple resource record
bob.sales.example.com

Each level of the hierarchy is divided by a period (that is, .). In Example 10.1, “A simple resource record”, com defines the top-level domain, example its subdomain, and sales the subdomain of example. In this case, bob identifies a resource record that is part of the sales.example.com domain. With the exception of the part furthest to the left (that is, bob), each of these sections is called a zone and defines a specific namespace.
Zones are defined on authoritative nameservers through the use of zone files, which contain definitions of the resource records in each zone. Zone files are stored on primary nameservers (also called master nameservers), where changes are made to the files, and secondary nameservers (also called slave nameservers), which receive zone definitions from the primary nameservers. Both primary and secondary nameservers are authoritative for the zone and look the same to clients. Depending on the configuration, any nameserver can also serve as a primary or secondary server for multiple zones at the same time.

10.1.2. Nameserver Types

There are two nameserver configuration types:
authoritative
Authoritative nameservers answer to resource records that are part of their zones only. This category includes both primary (master) and secondary (slave) nameservers.
recursive
Recursive nameservers offer resolution services, but they are not authoritative for any zone. Answers for all resolutions are cached in a memory for a fixed period of time, which is specified by the retrieved resource record.
Although a nameserver can be both authoritative and recursive at the same time, it is recommended not to combine the configuration types. To be able to perform their work, authoritative servers should be available to all clients all the time. On the other hand, since the recursive lookup takes far more time than authoritative responses, recursive servers should be available to a restricted number of clients only, otherwise they are prone to distributed denial of service (DDoS) attacks.

10.1.3. BIND as a Nameserver

BIND consists of a set of DNS-related programs. It contains a monolithic nameserver called named, an administration utility called rndc, and a debugging tool called dig. Refer to Chapter 7, Controlling Access to Services for more information on how to run a service in Red Hat Enterprise Linux.