DNS Lookup

What happens when you type google.com in your browser and hit enter?

How do we go from typing google.com to a page with the colourful Google logo and a search bar with the ability to answer any and all of our questions? How does your browser even know which page to show? And why do some pages take longer to load whereas others appear almost instantaneously?

Well, all of this happens through a process called DNS resolution. But before we get into that, let us understand what DNS really is.

So, what is DNS?

DNS, Domain Name System, is basically the internet’s Yellow Pages. It allows you to reach Facebook’s home page without remembering its IP address, just like Yellow Pages helps you call Anand Sweets[1] [2] without having to remember their contact number. We as users access web pages through their domain names like www.codekarle.com, but web browsers interact with servers through IP addresses like 192.168.1.1, to fetch the web page. DNS translates the domain names to IP addresses so that browsers can understand the request and fetch the relevant web page.

How does DNS work?

The process of translation of domain names to IP addresses is known as DNS resolution. Once the browser makes the request to the DNS server, the query passes through a bunch of other servers to find the domain name — IP address mapping. Let us look at this whole process in a little more detail.

The DNS resolution pipeline has four levels of servers that work together to find the correct IP address.

DNS recursor -> Root Nameserver -> TLD Nameserver -> Authoritative Nameserver

DNS Recursor is the server responsible for receiving requests from web browsers and makes further requests, if needed, to find the correct IP address. It does this by making multiple requests till it finds the authoritative nameserver that has the mapping for requested domain name. If no record is found it returns a timeout error. To optimise the lookup at this level itself, our recursive resolver maintains a cache where it stores the recently looked up records. This is why you’ll notice, some pages that are opened more frequently take less time to load.

Root Nameserver, our next stop, is actually the first step in the process of DNS resolution. If the DNS recursor is unable to find the mapping in its cache, it reaches out to the root nameserver. Root nameserver has information about the root zone i.e. Top Level Domains like .com, .org, .net, .in, .au, etc. For each TLD the root server returns the IP address for its TLD’s content.

There are 13 root servers which are reachable with 13 IP addresses. For better reach, collectively 1300 instances of root servers run across the globe, but at any time from any given location, only 13 root servers are accessible.

TLD Nameserver is our next stop. This server contains information of all domain names ending in a common extension. For example if we search www.codekarle.com, the recursive resolver at this point will reach out to the .com TLD nameserver which will respond with the authoritative nameserver for that codekarle.com.

Authoritative Nameserver is the last step in the resolution process. It contains information specific to the domain name and responds with the IP address of the server found.

Now this seems like a fairly long process. Isn’t there a way to optimize this? Of course there is and the most obvious thing that comes to mind is caching. Usually there is some level of caching implemented at every level to avoid further look ups and save some time. But even before the process begins, we have a local copy of recent DNS lookups on our machine itself..

DNS lookup and caching

Browser cache — Most browsers maintain a local DNS cache where they store the mappings for more frequently accessed domain names. If you think about it, it kind of makes sense, since closer the cache, faster the rendering and better the experience. So browser level DNS Cache is the first place we check.

OS cache — If the mapping is not found in browser DNS cache, OS level DNS resolver is the second place we check. The process responsible for this check is called the stub resolver. If the record is found by the stub resolver, IP address is returned to the browser which fetch the web page and renders it. If not, the request now goes out of our machine. Some routers also maintain a DNS cache, and this is the next place we check. Again, if the mapping is found, IP address is sent back to the browser, otherwise the request is sent to the ISP’s DNS recursor. ISP’s recursor checks in its own DNS cache, if the record is found, it is returned to the browser. Otherwise, the DNS lookup is initiated.

So, to summarise…

-> When the user types, let’s say, codekarle.com in the browser and hits enter, the browser first checks its DNS cache. If the IP address is found, it fetches the webpage and renders it.

-> If not, OS level DNS cache is the next stop.

-> If the IP address is not found here as well, the router level DNS cache, if it is maintained, is the next stop.

-> Same drill, if the IP address is found it is returned to the browser, otherwise the request is sent to the ISP’s recursive resolver..

-> ISP checks its own cache, if the IP address is found it is returned to the browser, otherwise the recursive resolver reaches out the the Root Nameserver.

-> Root Nameserver returns the address of the relevant TLD nameserver, in our case it will be .com nameserver to the resolver.

-> Resolver now reaches out to the TLD server which responds with the authoritative nameserver for codekarle.com.

-> Resolver now reaches out to the codekarle.com authoritative nameserver to fetch the IP address and returns it to the web browser.

-> Now the browser makes an HTTP request to this IP address which returns the webpage to the browser to render.

That’s all about DNS resolution from our side. If there is something we missed, let us know in the comments. Do check out our website and YouTube channel for more such content!