When the Internet was just started and only had a few hundred computers connected to it, name resolution was very simple and easy to maintain. The original TCP/IP specification implemented name resolution using a special text file called HOSTS. A copy of this file was stored on every computer system on the Internet. The HOSTS file contained a list of IP addresses for every computer on the Internet that mapped to the corresponding system names. A central HOSTS file was updated and distributed on a daily basis. This worked fairly well until there were a few thousand systems connected to the Internet. Even though TCP/IP systems still have a HOSTS file on their computer, the HOSTS file is no longer the primary source for name resolution. Originally, the concept of having a central supercomputer for name resolution was considered, but this solution would also reach a limit so it was not very practical. The idea of delegating the name resolution process would mitigate the concerns of a limiting process. The DNS hierarchy was born and to this day, still growing and expanding in size. The root domain is comprised of 13 DNS systems dispersed around the world, known collectively as the DNS root servers. While there are 13 IP addresses that represent these systems, there are actually more than 13 servers. Some of the IP addresses are actually load balanced virtual IPs, so there may be two or more DNS servers that are load sharing some of the IP addresses. Here is the list of the 13 roots servers, by hostname. While the DNS root servers establish the hierarchy, most of the name resolution process is delegated to other DNS servers. Just below the DNS root in the hierarchy are the top-level domain servers. These top-level DNS servers handle top-level domains such as com, net, org, edu, gov, mil, etc. The top-level DNS servers delegate to thousands of second-level DNS servers. Second-level domain names are sold to companies and other organizations. The second level of this structure is comprised of millions of domain names. Second-level DNS servers can further delegate the zone, but most commonly store the individual host records for a domain name, such as the most common host record www. For example, the corp.com domain has a server that has a DNS alias called www with the IP address of 192.168.0.1. Only the DNS server controlling the corp.com domain stores the actual IP address for the host record www.corp.com. No other DNS system that does not store the corp.com zone will have this information. The DNS system will provide the resolver (the client making the DNS request) with referrals until the resolver reaches the DNS server that is hosting this zone. Once the DNS server hosting this zone receives the query from the resolver, it will send the resolver with an answer to the query.
DNS Namespace
The DNS namespace works in a manner similar to how your computer’s file system works. The DNS namespace is a hierarchy of DNS domains and individual hostnames organized into a tree-like structure. Each domain is similar to a folder. Just like in the typical folder structure, a folder can contain folders or documents. In DNS, a domain can contain other domains or records.
Resource Records
At second-level DNS servers, you typically find resource records. Resource records map services and hostnames to IP addresses. For example, the most common resource record is the host (A) record. A hostname simply maps a name to an IP address. The most common hostname is the www record. In some cases, it is preferable to use an alias (CNAME) record to point another host record. For example, if a server has multiple names associated with a server, you could create a host (A) record called server1 and map that to the IP address of the computer. Then create several alias (CNAME) records, such as www, ftp, mail, that map back to the same hostname. Here is a list of the most common DNS records used within a zone.
Name Resolution Process
The name resolution process has not significantly changed since DNS was first designed. When a DNS resolver (DNS client) needs to resolve a hostname to be able to access a resource, it must first contact a DNS server. The DNS server that it contacts depends on its client TCP/IP configuration. Either the DNS client configuration is included in the DHCP configuration, or it must be manually configured in the client settings. For computers within a private network, it is recommended that they be configured to point to internal DNS servers. For systems on the internet, they can be configured to point to their ISP’s DNS servers, or one of the many public DNS servers on the Internet, such as Google’s public servers (8.8.4.4 and/or 8.8.8.8). In the graphic shown above, the name resolution process depicts eight steps that need to be taken to resolve a hostname from a DNS client. We can use this graphic to discuss a typical example in more detail. In the following example, a DNS client is trying to access a web server on the Internet. Before the client can communicate with the web server, the web server’s hostname must be resolved to an IP address.
Step 1: DNS client queries ISP DNS server to resolve the host name www.domain.com.Step 2: The ISP web server checks its DNS cache and local zones, if no match is found, the DNS server will query the root DNS server.Step 3: The root DNS server responds back to the ISP DNS server with a referral so that the request can be sent to the .COM DNS servers.Step 4: The ISP DNS server sends the query to the .COM DNS server.Step 5: The .COM DNS server responds back to the ISP DNS server with a referral so that the request can be sent to the DOMAIN.COM DNS servers.Step 6: The ISP DNS server sends the query to the DOMAIN.COM DNS server.Step 7: The DOMAIN.COM DNS server responds back to the ISP DNS server with the answer to the query for www.domain.com.Step 8: The ISP DNS server caches the answer and sends the answer back to the resolver.
The resolver can now initiate direct communication with the web server since the resolver (DNS client) now has the IP address of the web server. You should also note that the DNS server will cache the information it received during this process. So that a future request for this hostname could be resolved from its cache rather than performing the entire process from beginning to end, as long as the future request is within the time-to-live (TTL) period of the cached record.
