DNS Servers

DNS Servers

In order to deal with the issue of scale, the DNS uses a large number of servers , organized in a hierarchical fashion and distributed around the world. No single DNS server has all of the mappings for all of the hosts in the internet. Instead, the mappings are distributed across the DNS servers. To a first approximation, there are three classes of DNS servers :

• Root DNS servers
• Top-Level (TLD) DNS servers
• Authoritative DNS servers

They are organized hierarchically in the figure shown below:

To understand how these three classes of servers interact, suppose a DNS client wants to determine the IP of the hostname ww.amazon.com. To a first approximation, the following events will take place:

• The client first contacts one of the root servers, which returns IP address for TLD servers for the top-level domain com.
• The client then contact one of these TLD servers, which returns the IP address of an authoritative server for amazon.com
• Finally, the client contact one of the authoritative servers of amazon.com, which returns the IP address for the hostname www.amazon.com.

We’ll soon examine this DNS lookup process in more detail. But let’s first take a closer look at these three classes of DNS servers.

Root DNS Servers

In the internet there are 13 root DNS servers (labelled A through M), most of which are located in North America.

An October 2006 map of the root DNS servers is shown in the figure below; a list of current root DNS servers is available vis [Root-servers 2012].

Although we have referred to each of the 13 DNS servers as if it were a single server, each “server” is actually a network of replicated servers, for both security and reliability purposes. All together, there are 247 root servers as of fall 2011.

Top-Level Domain (TLD) Servers

These servers are responsible for top-level domains such as com, org, net, edu & gov, and all of the country top-level domains such as uk, fr, ca, and jo. The company Verisign Global Registry Services maintains the TLD servers for the com top-level domain, and the company Educause maintains the TLD servers for the edu top-level domain.

Authoritative DNS Servers

Every organization with public accessible hosts (such as web servers and mail servers) on the internet must provide publicly accessible DNS records that map the names of those hosts to IP addresses. An organization’s authoritative DNS server houses these DNS records. An organization can choose to implement its own authoritative DNS server to hold these records; alternatively, the organization can pay to have these records stored in authoritative DNS server of some service provider. Most universities and large companies implement and maintain their own primary and secondary (backup) authoritative DNS server.

The root, TLD, and authoritative DNS servers all belong to the hierarchy of DNS servers . There is another important type of DNS server 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, an 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 proved the host with the IP address 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. For an institutional ISP, it is typically separated from the host by no more than a few routers. 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, we we’ll discuss in more detail below.

Let’s take a look at a simple example. Suppose the host cis.polu.edu desires the IP address of gaia.cs.unmass.edu. Also suppose that Polytechnic’s local DNS server is called dns.poly.edu and that an authoritative DNS server for gaia.cs.unmass.edu is called dns.unmass.edu. As shown in the figure below:

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.unmass.edu. The local DNS server forwards the query message to a root DNS server. The root DNS server takes note 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 one of these TLD servers. The TLD server takes note of the unmass.edu suffix and responds with the IP address of the authoritative DNS server for the University of Massachusetts, namely, dns.unmass.edu. Finally, the local DNS server resends the query message directly to dns.unmass.edu, which responds with the IP address of gaia.cs.unmass.edu. Note that in this example, in order to obtain the mapping for one hostname, eight DNS messages were sent: for query messages and four reply messages! We’ll soon see how DNS caching reduces this query traffic.

Our previous example assumed that the TLD server knows the authoritative DNS server for the hostname. In general this not always true. Instead, the TLD server may know only of an intermediate DNS server, which in turn knows the authoritative DNS server for the hostname. For example, suppose again that the University of Massachusetts has a DNS server for the university, called dns.unmass.edu. Also suppose that each of the departments at the University of Massachusetts has its own DNS server, and that each department DNS server is authoritative for all hosts in the department. In this case, when the intermediate DNS server, dns.unmass.edu receives a query for a host with a hostname ending with cs.unmass.edu, which is authoritative for all hostnames ending with cs.unmass.edu. The local DNS server dns.polu.edu then sends the query to the authoritative DNS server, which returns the desired mapping to the local DNS server, which in turn returns for mapping to the requesting host. In this case, a total of 10 DNS messages are sent!

The example shown in the figure above makes use of both recursive queries 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 thee queries are iterative since all of the replies are directly returned to dns.poly.edu. In theory, any DNS query can be iterative or recursive. For example, the figure below, shows a DNS query chain for which all of the queries are recursive.

In practice, the queries typically follows the pattern in the figure above: The query from the requesting host to the local DNS server is recursive, and the remaining queries are iterative.

DNS Caching

Our discussion thus far has ignored DNS caching , a critically important feature of the DNS system. In truth, DNS extensively exploits DNS caching in order to improve the delay performance and to reduce the number of DNS messages ricocheting around the internet. The idea behind DNS caching 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 mapping in its local memory. For example, in figure 2.21, 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).

As an example, suppose that a host apricot.poly.edu queries dns.polu.edu for the IP address for the hostname cnn.com. Furthermore, suppose that a few hours later, another Polytechnic University host say, kiwi.poly.fr, also queries dns.poly.edu with the same hostname. Because of caching , the local DNS server will be able to immediately return the IP address of cnn.com to this second requesting host without having to query any other DNS servers. A local DNS server can also cache the IP address of TLD servers, thereby allowing the local DNS server to bypass the root DNS servers in a query chain (this often happens).