21.1 Overview

DNS stands for Domain Naming System. A domain is any logical or physical collection of related hosts or sites. A naming system is best visualized as an inverted tree of information that corresponds to full qualified hostnames (see Figure 21.1).

Figure 21.1: Domain names form a tree of information

The parts of a fully qualified name are separated from one another with dots. For example,

here.uofa.edu

This name describes the machine here that is part of the uofa subdomain of the edu top-level domain. In Figure 21.1 the dot at the top is the "root" of the tree. It is implied but never [1] included in fully-qualified domain names:

[1] Well, hardly ever. It can be used under some circumstances to prevent the local domain from being accidently appended improperly.

here.uofa.edu.
             
             implied

The root corresponds to (is served by) actual machines. [2] Each has knowledge of all the top-level domains (such as gov, com, etc.) and the server machines for those domains. Each of the top-level domain's servers knows of one or more machines with knowledge of the next level below. For example, the server for edu "knows" about the subdomains uofa, uofb, and uofc but may not know about anything below those subdomains, nor about the other domains next to itself such as com. [3]

[2] This used to be a single machine named ns.internic.net but is now several machines named a.root-servers.net, b.root-servers.net, and so on.

[3] There is also a type of server called "caching." This type doesn't originate information about domains but is able to look up and save information and to supply it on request.

A knowledgeable machine, one that can look up or distribute information about its domain and subdomains, is called a name server. Each little black square in the figure represents a name server for a portion of a domain. Each is required to have knowledge only of what is immediately below it. This minimizes the amount of knowledge any given name server must store and administer.

To illustrate the way this distributed information is used, see Figure 21.2 for the steps that are taken when sendmail on here.uofa.edu (the local host) attempts to connect to fbi.dc.gov (the remote host) to send an email message to a user there.

Figure 21.2: How DNS lookups are performed

1. The local sendmail needs the IP number of the remote host to initiate a network connection. The local sendmail asks its local name server (say, mail.uofa.edu) for that address. The mail.uofa.edu name server may already know the address (having cached that information during a previous inquiry). If so, it gives the requested address to the local sendmail, and no further DNS requests need to be made. If the local name server doesn't have that information, it contacts other name servers for the needed information.

2. In the case of fbi.dc.gov the local name server next contacts one of the root servers (the dot in the big box in our example). A root server will likely not have the information requested but will indicate the best place to inquire. For our example, the root server recommends the name server for the .gov domain and provides our local name server with the address of that .gov domain server machine.

3. The local name server then contacts the .gov name server. This process continues until a name server provides the needed information. As it happens, any name server can return the final answer if it happens to have it in its cache. For our example, .gov knows the address for fbi.dc.gov. It returns that address to the local name server, which in turn returns the address to the local sendmail.

Note that this is a simplified description. The actual practice can be more or less complex depending on who is "authoritative" about which machines and domains and what is cached where.

The sendmail program needs the IP address of the machine to which it must connect. That address can be returned by name servers in three possible forms:

• An MX (Mail eXchanger) record lists one or more machines that have agreed to receive mail for a particular site or machine. Multiple MX records are tried in order of cost [4] (least to most). An MX record need not point to the original receiving host. MX records always take precedence over A records.

  [4] Technically, this field is called the preference. We use cost to clarify that lower values are preferable, whereas preference wrongly connotes that higher values are preferable.

• An A (Address) record gives the IP address directly.

• A CNAME (Canonical NAME, or alias) record refers sendmail to the real name, which may have an A record or MX records.