Полезная информация

DNS & BIND

DNS & BINDSearch this book
Previous: 1.2 On the Internet and internetsChapter 1
Background
Next: 1.4 The History of BIND
 

1.3 The Domain Name System, in a Nutshell

The Domain Name System is a distributed database. This allows local control of the segments of the overall database, yet data in each segment are available across the entire network through a client-server scheme. Robustness and adequate performance are achieved through replication and caching.

Programs called name servers constitute the server half of DNS's client-server mechanism. Name servers contain information about some segment of the database and make it available to clients, called resolvers. Resolvers are often just library routines that create queries and send them across a network to a name server.

The structure of the DNS database, shown in Figure 1.1, is very similar to the structure of the UNIX filesystem. The whole database (or filesystem) is pictured as an inverted tree, with the root node at the top. Each node in the tree has a text label, which identifies the node relative to its parent. This is roughly analogous to a "relative pathname" in a filesystem, like bin. One label - the null label, or "" - is reserved for the root node. In text, the root node is written as a single dot ("."). In the UNIX filesystem, the root is written as a slash ("/").

Figure 1.1: The DNS database versus a UNIX filesystem

Figure 1.1

Each node is also the root of a new subtree of the overall tree. Each of these subtrees represents a partition of the overall database - a "directory" in the UNIX filesystem, or a domain in the Domain Name System. Each domain or directory can be further divided into additional partitions, called subdomains in DNS, like a filesystem's "subdirectories." Subdomains, like subdirectories, are drawn as children of their parent domains.

Every domain has a unique name, like every directory. A domain's domain name identifies its position in the database, much as a directory's "absolute pathname" specifies its place in the filesystem. In DNS, the domain name is the sequence of labels from the node at the root of the domain to the root of the whole tree, with "." separating the labels. In the UNIX filesystem, a directory's absolute pathname is the list of relative names read from root to leaf (the opposite direction to DNS, as shown in Figure 1.2), using a slash to separate the names.

Figure 1.2: Reading names in DNS and in a UNIX filesystem

Figure 1.2

In DNS, each domain can be administered by a different organization. Each organization can then break its domain into a number of subdomains and dole out responsibility for those subdomains to other organizations. For example, the InterNIC runs the edu (educational) domain, but assigns U.C. Berkeley authority over the berkeley.edu subdomain (Figure 1.3). This is something like remotely mounting a filesystem: certain directories in a filesystem may actually be filesystems on other hosts, mounted from a remote host. The administrator on host winken, for example (again, Figure 1.3), is responsible for the filesystem that appears on the local host as the directory /usr/nfs/winken.

Figure 1.3: Remote management of subdomains and of filesystems

Figure 1.3

Domain names are used as indexes into the DNS database. You might think of data in DNS as "attached" to a domain name. In a filesystem, directories contain files and subdirectories. Likewise, domains can contain both hosts and subdomains. A domain contains those hosts and subdomains whose domain names are within the domain.

Each host on a network has a domain name, which points to information about the host (see Figure 1.4). This information may include IP addresses, information about mail routing, etc. Hosts may also have one or more domain name aliases, which are simply pointers from one domain name (the alias) to another (the official or canonical domain name). In the figure, mailhub.nv... is an alias for the canonical name rincon.ba.ca....

Figure 1.4: An alias in DNS pointing to a canonical name

Figure 1.4

Figure 1.5: Solving the name collision problem

Figure 1.5

Why all the complicated structure? To solve the problems that HOSTS.TXT had. For example, making domain names hierarchical eliminates the pitfall of name collisions. Each domain has a unique domain name, so the organization that runs the domain is free to name hosts and subdomains within its domain. Whatever name they choose for a host or subdomain, it won't conflict with other organizations' domain names, since it will end in their unique domain name. For example, the organization that runs hic.com can name a host puella (as shown in Figure 1.5), since it knows that the domain host's domain name will end in hic.com, a unique domain name.


Previous: 1.2 On the Internet and internetsDNS & BINDNext: 1.4 The History of BIND
1.2 On the Internet and internetsBook Index1.4 The History of BIND