Convert IP Address to DNS Names

Besides converting domain names into Internet Protocol (IP) addresses, the DNS system can do the reverse, which is convert IP addresses into names. This conversion is done by associating a domain name with a network address and placing this domain name in the top level in-addr.arpa domain. Suppose that our company has the Class C network address 196.175.34.0. The associated in-addr.arpa domain name is 34.175.196.in-addr.arpa. This name is created from the network address by reversing the order of the bytes in the network address and tacking in-addr.arpa at the end.

This reverse lookup convention may seem a bit strange, but, it has a certain logic to it. The conventions for IP addresses are such that the left-most bytes of a network address pertain to more general networks; each additional byte, moving from left to right, makes the address more specific. As we saw previously, the conventions for domain names are exactly the opposite. To convert a network address into a domain name, then, we must reverse the order of the bytes in the network address. With this naming convention, suppose we want to find the hostname of the machine with IP address 204.175.34.143. We extract the network portion of this IP address (204.175.34) and look in the DNS database under the domain name
34.175.204.in-addr.arpa for the host number 143.

The process of finding the IP address is achieved by searching the DNS (Domain Name Servers) until a match on the domain name is found. This process is also known as DNS lookup, NSLOOKUP. The process of finding the host name (or domain name) from an IP address involves sending a message to the IP address and requesting the computer located at that IP address to return its name. Usually this will be the same as the domain name. However, many computers host many domains so the host name may be one of the domain names hosted or it could be something totally different.
There are some special IP addresses. 127.0.0.1 is always the IP address of every computer. No matter which computer you use, it will always have an IP address of 127.0.0.1 and a name of localhost. In addition, a computer can have more than one IP address. In order to connect to other computers it will have an IP address that is known to other computers.

Before the page and any resource on the page is loaded, the DNS must be resolved so the browser can establish a TCP connection to make the HTTP request. In addition, for every external resource referenced by a URL, the DNS resolution must complete the same steps (per unique domain) before the request is made over HTTP. The DNS Resolution process starts when the user types a URL address on the browser and hits Enter. At this point, the browser asks the operating system for a specific page, in this case google.com.

Since the operating system does not know where "www.google.com" is, it queries a DNS resolver. The query the OS sends to the DNS Resolver has a special flag that tells it is a "recursive query". This means that the resolver must complete the recursion and the response must be either an IP address or an error.

The resolver starts by querying one of the root DNS servers1for the IP of “www.google.com.” This query does not have the recursive flag and therefore is an “iterative query,” meaning its response must be an address, the location of an authoritative name server, or an error.
There are 13 root server clusters named A-M with servers in over 380 locations. The root is represented in the hidden trailing "." at the end of the domain name. Typing this extra "." is not necessary as your browser automatically adds it.

These root servers hold the locations of all of the top level domains (TLDs) such as .com, .de, .io, and newer generic TLDs such as .camera. They are managed by 12 different organizations that report to the Internet Assigned Numbers Authority (IANA), such as Verisign, who controls the A and J clusters. All of the servers are copies of one master server run by IANA. The root does not have the IP info for "www.google.com", but it knows that .com might know, so it returns the location of the .com servers. The root responds with a list of the 13 locations of the .com gTLDservers, listed as NS or "name server" records.

Next the resolver queries one of the .com name servers for the location of google.com. Like the Root Servers, each of the TLDs have 4-13 clustered name servers existing in many locations. There are two types of TLDs: country codes (ccTLDs) run by government organizations, and generic (gTLDs). Every gTLDhas a different commercial entity responsible for running these servers. In this case, we will be using the gTLDservers controlled by Verisign, who run the .com, .net, .edu, and .govamong gTLDs.

Each TLD server holds a list of all of the authoritative name servers for each domain in the TLD. For example, each of the 13 .com gTLDservers has a list with all of the name servers for every single .com domain. The .com gTLDserver does not have the IP addresses for google.com, but it knows the location of google.com'sname servers. The .com gTLDserver responds with a list of all of google.com'sname servers, each represented as NS, or "name server" record.

At this point the operating system, now in possession of www.google.com’s IP address, provides the IP to the Application (Browser), which initiates the TCP connection to start loading the page. For more information of this process, you can visit the Catchpoint blog to learn more about the anatomy of HTTP. As mentioned earlier, this is a worst case scenario. In most cases, if the user has recently accessed URLs of the same domain, or other users relying on the same DNS resolver have done such requests, there will be no DNS resolution required, or it will be limited to the query on the local DNS resolver.
In this DNS non-cached case, four servers were involved, hence a lot could have gone wrong. The end user has no idea what is happening behind the scenes; they are simply are waiting for the page to load and all of these DNS queries have to happen before the browser can request the webpage.
This is why we stress the importance of fast DNS. You can have a fast and well-built site, but if your DNS is slow, your webpage will still have poor response time.

Click the Quiz link below to take a brief multiple-choice quiz on Domain Name Server basics.
Domain Name Service Basics - Quiz