We human beings can be identified in many ways. For example, we can be identified by the names that appear on our birth certificates. We can be identified by our social security numbers. We can be identified by our driver's license numbers. Although each of these identifiers can be used to identify people, within a given context, one identifier may be more appropriate than an other. For example, the computers at the IRS (the infamous tax collecting agency in the US) prefer to use fixed-length social security numbers rather than birth-certificate names. On the other hand, ordinary people prefer the more mnemonic birth-certificate names rather than social security numbers. (Indeed, can you imagine saying, "Hi. My name is 132-67-9875. Please meet my husband, 178-87-1146.")
Just as humans can be identified in many ways, so too can Internet hosts. One identifier for a host is its hostname. Hostnames -- such as cnn.com, www.yahoo.com, gaia.cs.umass.edu and surf.eurecom.fr -- are mnemonic and are therefore appreciated by humans. However, hostnames provide little, if any, information about the location within the Internet of the host. (A hostname such as surf.eurecom.fr, which ends with the country code .fr, tells us that the host is in France, but doesn't say much more.) Furthermore, because hostnames can consist of variable-length alpha-numeric characters, they would be difficult to process by routers. For these reasons, hosts are also identified by so-called IP addresses. We will discuss IP addresses in some detail in Chapter 4, but it is useful to say a few brief words about them now. An IP address consists of four bytes and has a rigid hierarchical structure. An IP address looks like 121.7.106.83, where each period separates one of the bytes expressed in decimal notation from 0 to 127. An IP address is hierarchical because as we scan the address from left to right, we obtain more and more specific information about where (i.e., within which network, in the network of networks) the host is located in the Internet. (Just as when we scan a postal address from bottom to top we obtain more and more specific information about where the residence is located). An IP address is included in the header of each IP datagram, and Internet routers use this IP address to route s datagram towards its destination.
We have just seen that there are two ways to identify a host -- a hostname and an IP address. People prefer the more mnemonic hostname identifier, while routers prefer fixed-length, hierarchically-structured IP addresses. In order to reconcile these different preferences, we need a directory service that translates hostnames to IP addresses. This is the main task of the the Internet's Domain Name System (DNS). The DNS is (i) a distributed database implemented in a hierarchy of name servers and (ii) an application-layer protocol that allows hosts and name servers to communicate in order to provide the translation service. Name servers are usually Unix machines running the Berkeley Internet Name Domain (BIND) software. The DNS protocol runs over UDP and uses port 53.
DNS is commonly employed by other application-layer protocols -- including HTTP, SMTP and FTP - to translate user-supplied host names to IP addresses. As an example, consider what happens when a browser (i.e., an HTTP client), running on some user's machine, requests the URL www.someschool.edu/index.html. In order for the user's machine to be able to send an HTTP request message to the Web server www.someschool.edu, the user's machine must obtain the IP address of www.someschool.edu. This is done as follows. The same user machine runs the client-side of the DNS application. The browser extracts the hostname, www.someschool.edu, from the URL and passes the hostname to the client-side of the DNS application. As part of a DNS query message, the DNS client sends a query containing the hostname to a DNS server. The DNS client eventually receives a reply, which includes the IP address for the hostname. The browser then opens a TCP connection to the HTTP server process located at that IP address. All IP datagrams sent to from the client to server as part of this connection will include this IP address in the destination address field of the datagrams. In particular, the IP datagram(s) that encapsulate the HTTP request message use this IP address. We see from this example that DNS adds an additional delay -- sometimes substantial -- to the Internet applications that use DNS. Fortunately, as we shall discuss below, the desired IP address is often cached in a "near by" DNS name server, which helps to reduce the DNS network traffic as well as the average DNS delay.
Like HTTP, FTP, and SMTP, the DNS protocol is an application-layer protocol since (i) it runs between communicating end systems (again using the client-server paradigm), and (ii) it relies on an underlying end-to-end transport protocol (i.e., UDP) to transfer DNS messages between communicating end systems. In another sense, however, the role of the DNS is quite different from Web, file transfer, and email applications. Unlike these applications, the DNS is not an application with which a user directly interacts. Instead, the DNS provides a core Internet function -- namely, translating hostnames to their underlying IP addresses, for user applications and other software in the Internet. We noted earlier in Section 1.2 that much of the "complexity" in the Internet architecture is located at the "edges" of the network. The DNS, which implements the critical name-to-address translation process using clients and servers located at the edge of the network, is yet another example of that design philosophy.
DNS provides a few other important services in addition to translating hostnames to IP addresses:
The DNS is specified in [RFC 1034] and [RFC 1035], and updated in several additional RFCs. It is a complex system, and we only touch upon key aspects of its operation here. The interested reader is referred to these RFCs and the book [Abitz 1993].
We now present a high-level overview of how DNS works. Our discussion shall focus on the hostname to IP address translation service. From the client's perspective, the DNS is a black box. The client sends a DNS query message into the black box, specifying the hostname that needs to be translated to an IP address. On many Unix-based machines, gethostbyname() is the library routine that an application calls in order to issue the query message. In Section 2.7, we shall present a Java program that begins by issuing a DNS query. After a delay, ranging from milliseconds to tens of seconds, the client receives a DNS reply message that provides the desired mapping. Thus, from the client's perspective, DNS is a simple, straightforward translation service. But in fact, the black box that implements the service is complex, consisting of large number of name servers distributed around the globe, as well as an application-layer protocol that specifies how the name servers and querying hosts communicate.
A simple design for DNS would have one Internet name server that contains all the mappings. In this centralized design, clients simply direct all queries to the single name server, and the name server responds directly to the querying clients. Although the simplicity of this design is attractive, it is completely inappropriate for today's Internet, with its vast (and growing) number of hosts. The problems with a centralized design include:
In summary, a centralized database in a single name server simply doesn't scale. Consequently, the DNS is distributed by design. In fact, the DNS is a wonderful example of how a distributed database can be implemented in the Internet.
In order to deal with the issue of scale, the DNS uses a large number of name servers, organized in a hierarchical fashion and distributed around the world. No one name server has all of the mappings for all of the hosts in the Internet. Instead, the mappings are distributed across the name servers. To a first approximation, there are three classes of DNS servers - root name servers, top-level domain (TLD) name servers, and authoritative name servers. These name servers, again to a first approximation, interact with each other and with the querying host as follows:
The root, TLD, and authoritative name servers all belong to the hierarchy of
DNS servers. There is another important type of DNS, called the local DNS
server. A local DNS server does not strictly belong to the hierarchy of servers
but is nevertheless central to the DNS architecture. Each ISP - such as a
university, and academic department, an employee's company, or a residential ISP
- has a local DNS server (also called a default name server). When a host
connects to an ISP, the ISP provides the host wit the IP addresses of one or
more of its local DNS servers (typically through DHCP). You can easily determine
the IP address of your local DNS server by accessing network status windows in
Windows or UNIX. A host's local DNS server is typically "close to" the host.
When a host makes a DNS query, the query is sent to the local DNS server, which
acts as a proxy, forwarding the query into the DNS server hierarchy as we'll
discuss in more detail below.
Let's take a look at a simple example. Suppose the host
cis.poly.edu desires the IP address of
gaia.cs.umass.edu. Also suppose that Polytechnic's local DNS server is
called dns.poly.edu and that an authoritative DNS
server for gaia.cs.umass.edu is called
dns.umass.edu. As shown in Figure 2.20, the host
cis.poly.edu first sends a DNS query message to its
local DNS server, dns.poly.edu. The query message
contains the hostname to be translated, namely,
gaia.cs.umass.edu. The local DNS server forwards the query message to a
root DNS server. The root DNS server takes not of the edu
suffix and returns to the local DNS server a list of IP addresses for TLD
servers responsible for edu. The local DNS server then
resends the query message to on of these TLD servers. The TLD server takes note
of the umass.edu suffix and responds with the IP
address of the authoritative DNS server for the U of Mass, namely,
dns.uass.edu. Finally, the local DNS server resends
the query message directly to dns.umass.edu, which
responds with the IP address of gaia.cs.umass.edu.
Note that in this example, in order to obtain the mapping for one hostname eight
DNS messages were sent: four query messages and four reply messages. DNS caching
reduces this query traffic.
Our discussion up to this point has assumed that the root name server knows the IP address of an authoritative name server for every hostname. This assumption may be incorrect. For a given hostname, the root name server may only know the IP address of an intermediate name server that in turn knows the IP address of an authoritative name server for the hostname. Suppose now that the University of Massachusetts has a name server for the university, called dns.umass.edu. Also suppose that each of the departments at University of Massachusetts has its own name server, and that each departmental name server is authoritative for all the hosts in the department. In this case, when the intermediate DNS server, dns.umass.edu, receives a query for a host with hostname ending with cs.umass.edu, it returns to dns.poly.edu the IP address of dns.cs.umass.edu, which is authoritative for all hostnames ending with cs.umass.edu. The local DNS server dns.poly.edu then sends the query to the authoritative DNS server, which returns the desired mapping to local DNS server, which in turn returns the mapping to the requesting host. In this case a total of 10 DNS messages are sent!
The example shown in Figure 2.20 makes use of both recursive and iterative queries. The query sent from cis.poly.edu to dns.poly.edu is a recursive query, since the query asks dns.poly.edu to obtain the mapping on its behalf. But the subsequent three queries are iterative since all of the replies are directly returned to dns.poly.edu. In theory, and DNS query can be iterative or recursive. In practice, the queries typically follow the pattern in Figure 2.20: the query from the requesting host to the local DNS server is recursive, and the remaining queries are iterative.
Our discussion this far has not touched on one important feature of the DNS: DNS caching. In reality, DNS extensively exploits caching in order to improve the delay performance and to reduce the number of DNS messages in the network. The idea is very simple. In a query chain, when a DNS server receives a DNS reply (containing, for example a mapping from a hostname to an IP address), it can cache the information in the reply in its local memory. For example, in Figure 2.20, each time the local DNS server dns.poly.edu receives a reply from some DNS server, it can cache any of the information contained in the reply. If a hostname/IP address pair is cached in a DNS server and another query arrives to the DNS server for the same hostname, the DNS server can provide the desired IP address, even if it is not authoritative for the hostname. Because hosts and mappings between hostnames and IP addresses are by no means permanent, DNS servers discard cached information after a period of time (often set to two days).