Chapter 7. The BIND DNS Server
On most modern networks, including the Internet, users locate other computers by name. This frees users from the daunting task of remembering the numerical network address of network resources. The most effective way to configure a network to allow such name-based connections is to set up a Domain Name Service (DNS) or a nameserver, which resolves hostnames on the network to numerical addresses and vice versa.
DNS associates hostnames with their respective IP addresses, so that when users want to connect to other machines on the network, they can refer to them by name, without having to remember IP addresses.
Use of DNS also has advantages for system administrators, allowing the flexibility to change the IP address for a host without affecting name-based queries to the machine. Conversely, administrators can shuffle which machines handle a name-based query.
DNS is normally implemented using centralized servers that are authoritative for some domains and refer to other DNS servers for other 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 the nameserver does not have an authoritative answer about the name the which host requested, 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. Then, with that information, it queries the authoritative nameservers to get the requested name.
In a DNS server such as BIND, all information is stored in basic data elements called resource records. A resource record is usually the fully qualified domain name (FQDN) of a host. Resource records are broken down into multiple sections. These sections are organized into a tree-like hierarchy consisting of a main trunk, primary branches, secondary branches, and so forth. Consider the following resource record:
bob.sales.example.com
When looking at how a resource record is resolved to find, for example, the IP address that relates to a particular system, read the name from right to left. Each level of the hierarchy is divided by a period (often called a "dot": “. ”). In this example, therefore, com defines the top-level domain for this resource record. The name example is a sub-domain under com, while sales is a sub-domain under example. The name furthest to the left, bob, identifies a resource record which is part of the sales.example.com domain.
Except for the first (leftmost) part of the resource record (bob), each section is called a zone. Zone defines a specific namespace. A zone contains definitions of resource records, which usually contain host-to-IP address mappings and IP address-to-host mappings, which are called reverse records).
Zones are defined on authoritative nameservers through the use of zone files, which define the resource records in that 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. Any nameserver can be a primary or secondary nameserver for multiple zones at the same time. It all depends on how the nameserver is configured.
There are two nameserver configuration types:
- authoritative
This category includes both primary (master) and secondary (slave) servers. Those servers answer only for resource records which are part of their zones.
- recursive
Offers resolution services, but is not authoritative for any zones. Answers for all resolutions are cached in memory for a fixed period of time, which is specified by the retrieved RR.
A nameserver may be one or both of these types. For example, a nameserver can be a master for some zones, a slave for others, and offer recursive services for others. However the best practice is not to combine authoritative and recursive servers due their absolutely different requirements. Authoritative servers are available for all clients and they should be available all the time otherwise it is not possible to resolve particular subtree of the DNS database. Recursive lookups take far more time than authoritative responses thus recursive servers should be available for a restricted number of clients. Otherwise recursive server could be easy target for distributed denial of service (DDoS) attack.
7.1.3. BIND as a Nameserver
BIND is set of DNS related programs. It contains a monolithic nameserver called
/usr/sbin/named, an administration utility called
/usr/sbin/rndc and DNS debugging utility called
/usr/bin/dig. More information about
rndc can be found in
Section 7.4, “Using rndc ”.
BIND stores its configuration files in the following locations:
-
/etc/named.conf
The configuration file for the named daemon
-
/var/named/ directory
The named working directory which stores zone and statistic files
Note
If you have installed the bind-chroot package, the BIND service will run in the /var/named/chroot environment. All configuration files will be moved there. As such, named.conf will be located in /var/named/chroot/etc/named.conf, and so on.
The next few sections review the BIND configuration in more detail.
