1210 Chapter 59
Before the advent of DNS, mappings between hostnames and IP addresses
were defined in a manually maintained local file, /etc/hosts, containing records of
the following form:# IP-address canonical hostname [aliases]
127.0.0.1 localhostThe gethostbyname() function (the predecessor to getaddrinfo()) obtained an IP address
by searching this file, looking for a match on either the canonical hostname (i.e., the
official or primary name of the host) or one of the (optional, space-delimited) aliases.
However, the /etc/hosts scheme scales poorly, and then becomes impossible, as
the number of hosts in the network increases (e.g., the Internet, with millions of hosts).
DNS was devised to address this problem. The key ideas of DNS are the following:z Hostnames are organized into a hierarchical namespace (Figure 59-2). Each
node in the DNS hierarchy has a label (name), which may be up to 63 characters.
At the root of the hierarchy is an unnamed node, the “anonymous root.”
z A node’s domain name consists of all of the names from that node up to the
root concatenated together, with each name separated by a period (.). For
example, google.com is the domain name for the node google.
z A fully qualified domain name (FQDN), such as http://www.kernel.org., identifies a host
within the hierarchy. A fully qualified domain name is distinguished by being
terminated by a period, although in many contexts the period may be omitted.
z No single organization or system manages the entire hierarchy. Instead, there
is a hierarchy of DNS servers, each of which manages a branch (a zone) of the
tree. Normally, each zone has a primary master name server, and one or more
slave name servers (sometimes also known as secondary master name servers), which
provide backup in the event that the primary master name server crashes.
Zones may themselves be divided into separately managed smaller zones. When a
host is added within a zone, or the mapping of a hostname to an IP address is
changed, the administrator responsible for the corresponding local name
server updates the name database on that server. (No manual changes are
required on any other name-server databases in the hierarchy.)
The DNS server implementation employed on Linux is the widely used Berkeley
Internet Name Domain (BIND) implementation, named(8), maintained by the
Internet Systems Consortium (http://www.isc.org/). The operation of this daemon
is controlled by the file /etc/named.conf (see the named.conf(5) manual page).
The key reference on DNS and BIND is [Albitz & Liu, 2006]. Information
about DNS can also be found in Chapter 14 of [Stevens, 1994], Chapter 11 of
[Stevens et al., 2004], and Chapter 24 of [Comer, 2000].
z When a program calls getaddrinfo() to resolve (i.e., obtain the IP address for) a
domain name, getaddrinfo() employs a suite of library functions (the resolver
library) that communicate with the local DNS server. If this server can’t supply
the required information, then it communicates with other DNS servers
within the hierarchy in order to obtain the information. Occasionally, this reso-
lution process may take a noticeable amount of time, and DNS servers employ
caching techniques to avoid unnecessary communication for frequently que-
ried domain names.