The Domain Name System is basically a database of host information. Admittedly, you get a lot with that: funny dotted names, networked name servers, a shadowy "namespace." But keep in mind that, in the end, the service DNS provides is information about internet hosts.
We've already covered some important aspects of DNS, including its client-server architecture and the structure of the DNS database. However, we haven't gone into much detail, and we haven't explained the nuts and bolts of DNS's operation.
In this chapter, we explain and illustrate the mechanisms that make DNS work. We also introduce the terms you'll need to know to read the rest of the book (and to converse intelligently with your fellow zone administrators).
First, though, let's take a more detailed look at concepts introduced in the previous chapter. We'll try to add enough detail to spice it up a little.
[7]Clearly this is a computer scientist's tree, not a botanist's.
If the root node's label actually appears in a node's domain name, the name looks as though it ends in a dot, as in "www.oreilly.com.". (It actually ends with a dot -- the separator -- and the root's null label.) When the root node's label appears by itself, it is written as a single dot (.) for convenience. Consequently, some software interprets a trailing dot in a domain name to indicate that the domain name is absolute. An absolute domain name is written relative to the root and unambiguously specifies a node's location in the hierarchy. An absolute domain name is also referred to as a fully qualified domain name, often abbreviated FQDN. Names without trailing dots are sometimes interpreted as relative to some domain name other than the root, just as directory names without a leading slash are often interpreted as relative to the current directory.
DNS requires that sibling nodes -- nodes that are children of the same parent -- have different labels. This restriction guarantees that a domain name uniquely identifies a single node in the tree. The restriction isn't really a limitation, because the labels need to be unique only among the children, not among all the nodes in the tree. The same restriction applies to the Unix filesystem: you can't give two sibling directories or two files in the same directory the same name. Just as you can't have two hobbes.pa.ca.us nodes in the namespace, you also can't have two /usr/bin directories (Figure 2-2). You can, however, have both a hobbes.pa.ca.us and a hobbes.lg.ca.us node, as you can have both a /bin directory and a /usr/bin directory.
The hosts are there, represented by domain names. Remember, domain names are just indexes into the DNS database. The "hosts" are the domain names that point to information about individual hosts. And a domain contains all the hosts whose domain names are within the domain. The hosts are related logically, often by geography or organizational affiliation, and not necessarily by network or address or hardware type. You might have 10 different hosts, each on a different network and perhaps even in a different country, all in the same domain.[8]
[8]One note of caution: don't confuse domains in the Domain Name System with domains in Sun's Network Information Service (NIS). Though an NIS domain also refers to a group of hosts, and both types of domains have similarly structured names, the concepts are quite different. NIS uses hierarchical names, but the hierarchy ends there: hosts in the same NIS domain share certain data about hosts and users, but they can't navigate the NIS namespace to find data in other NIS domains. NT domains, which provide account management and security services, also don't have any relationship to DNS domains.Domain names at the leaves of the tree generally represent individual hosts and may point to network addresses, hardware information, and mail routing information. Domain names in the interior of the tree can name a host and can point to information about the domain. Interior domain names aren't restricted to one or the other. They can represent both the domain they correspond to and a particular host on the network. For example, hp.com is both the name of the Hewlett-Packard Company's domain and the domain name of the hosts that run HP's main web server.
The type of information retrieved when you use a domain name depends on the context in which you use it. Sending mail to someone at hp.com returns mail routing information, while telneting to the domain name looks up the host information (in Figure 2-6, for example, hp.com's IP address).
[9]The terms domain and subdomain are often used interchangeably, or nearly so, in DNS and BIND documentation. Here, we use subdomain only as a relative term: a domain is a subdomain of another domain if the root of the subdomain is within the domain.A simple way of deciding whether a domain is a subdomain of another domain is to compare their domain names. A subdomain's domain name ends with the domain name of its parent domain. For example, the domain la.tyrell.com must be a subdomain of tyrell.com because la.tyrell.com ends with tyrell.com. Similarly, it's a subdomain of com, as is tyrell.com.
Besides being referred to in relative terms, as subdomains of other domains, domains are often referred to by level. On mailing lists and in Usenet newsgroups, you may see the terms top-level domain or second-level domain bandied about. These terms simply refer to a domain's position in the domain name space:
The internet class is by far the most popular. (We're not really sure if anyone still uses the Chaosnet class, and use of the Hesiod class is confined mostly to MIT.) In this book, we concentrate on the internet class.
Within a class, records also come in several types, which correspond to the different varieties of data that may be stored in the domain name space. Different classes define different record types, though some types are common to more than one class. For example, almost every class defines an address type. Each record type in a given class defines a particular record syntax, which all resource records of that class and type must adhere to. (For details on internet resource record types and their syntaxes, see Appendix A, "DNS Message Format and Resource Records".)
If this information seems sketchy, don't worry -- we'll cover the records in the internet class in more detail later. The common records are described in Chapter 4, "Setting Up BIND", and a more comprehensive list is included as part of Appendix A, "DNS Message Format and Resource Records".