Section 3.1. A Brief Tour of DNS

3.1. A Brief Tour of DNS

Your mobile telephone number is used to reach your phone while you travel from place to place and even if you switch providers. When you register an Internet domain name, you can be assured that it is unique and you can publish it so others can use it to find you. If you later move your host machine(s) to a different location or IP address, this name that you have advertised will still correctly direct people to your web site. Some central authority must administer telephone numbers and domain names if we want to ensure consistency and stability. This section provides a quick overview of DNS.

3.1.1. The Namespace

Consider a typical URL, such as the one for Apple's Bonjour home page:

http://developer.apple.com/bonjour/

The http identifies the protocol as the hypertext transfer protocol. The developer.apple.com identifies the machine where the resource can be found, and /bonjour/ identifies the particular resource on that machine.

A domain name read left to right moves from the specific to the general. So, developer is a node in the apple.com domain and apple is a node in the com domain. There are other domains at the same level as com that sit under the root of the domain name space in the same way that bin, dev, and usr directories sit under the root of a Mac OS X machine. On a Mac OS X or other Unix machine, you might have a path such as /usr/lib. The leading slash (/) character is used as a separator, and we also think of the root of a Unix file system as being (/) and navigate to the root by typing cd / in a terminal window. When you type a filename or pathname in Unix without a leading slash, it's interpreted relative to your current working directory, whatever that might be. If you're not currently in the directory you thought you were in, then the filename or pathname might not actually refer to the file you intended. When you type a filename or pathname with a leading slash, it's an absolute name, relative to the root of the file system, so there's no ambiguity.

In the same way, a domain name that doesn't end in a final dot (.) is interpreted relative to your current DNS search list. Suppose you mistype developer.apple.com as devloper.apple.com, and there's no final dot. Your system will first look up devloper.apple.com. When it finds this does not exist, it will go through your list of search domains, appending each in turn, trying names like devloper.apple.com.apple.com., devloper.apple.com.starbucks.com., or devloper.apple.com.whatever.org., depending on what's in the DNS searchlist your machine received from the DHCP server. If some joker sets up a real web server called devloper.apple.com.whatever.org., then you may find you've connected to that instead of the one you expected. Just like putting a leading slash on a pathname, you can eliminate this ambiguity by making the domain name absolute (i.e., fully qualified) by adding a . to the end. So, developer.apple.com. is the fully qualified name.

The root doesn't really have a name. You can think of it as the null character to the right of the trailing . or you can think of it as the final . itself. However you think of this trailing ., a fully qualified name is complete in itself and DNS search domains will not be appended.

Left-to-Right or Right-to-Left?

With Unix and DOS pathnames, you start with the top-level directory at the left, and then with each successive pathname component, you further narrow the scope until you've identified the one specific file you want.

Similarly, with telephone numbers, you start with the country code at the left, then the area code, then the exchange, then finally the last digits that identify the specific telephone you're calling.

IP addresses work the same way. When you see any IP address that begins with 17, that means the address is somewhere at Apple. Successive digits narrow the scope to the particular building, particular floor, and finally, the specific host being addressed.

Postal addresses are written the opposite way: you begin with the specific person or street address first and end with the city and country.

In the United States, domain names are written like postal addresses, not telephone numbers or IP addresses: you start with the specific and end with the general top-level domain (e.g., com, edu, mil) or country code (e.g., us, uk, fr).

For a long time in England, domain names were written like telephone numbers, starting with the country code first, so the domain name for Sidney Sussex College Cambridge was written uk.ac.cam.sid instead of sid.cam.ac.uk. These days, England writes its domain names with the root on the right, like the rest of the world, though, in an ironic twist, so-called "reverse-DNS" naming has become popular in all sorts of other areas, such as Java package names (e.g., com.sun.mail.smtp), so the debate over left-to-right versus right-to-left continues.

3.1.2. Administration of DNS

DNS is robust because there is no central authority responsible for all of the nodes. From the root, there are top-level domains that can be viewed as independent sub-trees. The top-level domains that exist directly below the root in the domain name hierarchy include the following:

• arpa, which is used for address-to-name mappings

• Generic domains, such as com, edu, gov, net, and org

• Geographical domains, which are country codes, such as ca (Canada) and jp (Japan)

Below the top-level domains are second-level domains. For example, apple.com is a second-level domain that sits under the top-level com domain. Apple Computer had to register this name and now they manage it. So, for example, Apple did not have to ask an outside authority for permission to add the node developer to apple.com. They manage their own domain as a separate zone and cannot possibly cause a name conflict with a domain outside of their zone. You can think of zones as sub-trees of the domain name space that are managed independently. The leaves of each sub-tree, such as developer, often correspond to a specific IP address.

When subdomains are created, they are often managed as separate zones, each responsible for their own administration. Within a university, the top-level domain may be split into domains for the different schools or departments. So, for example, the rice.edu domain has a subdomain for the computer science department, cs.rice.edu. The administrator of rice.edu does not need to be concerned about how cs.rice.edu is administered. This responsibility has been delegated. A node named exciton has been added to the cs.rice.edu zone. This information needs to be stored in a name server for cs.rice.edu so that the name exciton.cs.rice.edu can be resolved.

3.1.3. Resolving Names

When you direct your browser to view www.apple.com, some work needs to go on below the surface to figure out where to direct your browser. In Figure 3-1, the ethereal application has been used to packet sniff to see what information is being exchanged. The figure highlights the response received from the default DNS server that the machine issuing the query is using. The query is www.apple.com: type A, class inet. For the domain name www.apple.com, a type-A query specifies that the IP address is requested and class inet specifies the query class is Internet. In principle, a DNS server could be used to store many other classes of data apart from just Internet-related data, but in practice, the only DNS class that is in widespread use today is class Internet.

The result of a successful DNS query gives you the DNS resource record associated with the requested name, type, and class. Often, you'll see a resource record's type and class referred to as the rrtype and rrclass. The resource data inside a resource record is called its rdata. Usually, the rdata has a particular structure that's determined by the record type. For example, the rdata for an IPv4 address record has to

Figure 3-1. DNS query for an IP address

be exactly four bytes. The rdata for a PTR or CNAME record doesn't have to be a fixed length, but it does have to be a properly formatted DNS name.

In the response, you can see that www.apple.com is actually the name of a CNAME record, which tells us that www.apple.com is not the real name of the machine; it's an alias for the real, or canonical, name. The rdata of the CNAME record gives the canonical name, www.apple.com.akadns.net. The second part of the answer provides the IP address for the name, www.apple.com.akadns.net.

You may have noticed that not all of the available information has been displayed in Figure 3-1. Some of the sections have been collapsed. You can also see some of this information using an application such as host, nslookup , or dig. The Domain Information Groper, or dig, is a command-line tool that can be used to run various queries. For example, the query dig developer.apple.com sends a query for the IP address corresponding to developer.apple.com. You can see the response from dig in Figure 3-2. It is fairly verbose and includes the answer, as well as a list of the six authoritative name servers and IP addresses for some of those name servers, so we don't have to begin our query at root next time. For fun, you can run dig with rice.edu and cs.rice.edu and compare the answers and the authority sections of the two responses.

You also may want to run nslookup with the command nslookup developer.apple.com. Run the query more than once and the answer should be something like this.

     Non-authoritative answer  :     Name:   developer.apple.com     Address: 17.254.2.129

The phrase "Non-authoritative answer" indicates that the answer came from a cached value and not a fresh query to an Apple name server. As in other applications, caching

Figure 3-2. Using dig to resolve a domain name to an IP address

improves performance at the risk of passing on information that is no longer correct. DNS is a distributed database of domain names and addresses, with caching of information higher up in the tree, that provides robust and efficient resolution of persistent globally unique names to relatively long-term globally unique IP addresses.