What is DNS server and how it works?

What is DNS server and how it works?

Typically, when you open your internet browser on your phone or laptop, you type in a website like google.com. And what happens is the home page of google loads; to no surprise, before something like this can even happen, we go through what is known as DNS resolution and what happens here is the browser requests something known as a DNS named server. This server will respond with the unique IP address of the actual human-readable name. The browser can cache that IP address and request the physical google server to get the response, which in this case would load what the google.com home page is. Now the reason that we have DNS is that memorizing complex IP addresses that are constantly changing. It would be a nearly impossible task. Human-readable domain names like google or facebook.com allow us to memorize vast amounts of websites with ease, so in this blogger post, we are going to understand the DNS resolution and mapping process.

After we start the process by making a client request to essentially, this domain before we reach out to the internet, the computer will check two layers of cache. And this is going to be the browser or operating system cache. We want to do this if we have made this request before; we can essentially short circuit the entire process of looking up the IP address. Because we've already done the heavy lifting, the IP address will be cached for a certain amount of time corresponding to the TTL or time to live before it expires and give you the IP address almost instantaneously.

For the sake of this blog post, we will assume that there was a cash miss and continue the process of the DNS lookup. So, what we do is we now continue to stage two, which is the client reaching out to what is known as the DNS resolver. Now DNS resolvers exist on the internet and are typically hosted by something like your internet service provider. You can also reach out and configure third-party DNS resolvers such as google or Cloudflare, but in this case, we're just going to use a simple ISP DNS resolver. Our browser or computer is reaching out into its cache. It will examine the discharge cache to see if it has made a similar discovery in the past. The difference is instead of just localized to your machine. It will take aggregation of all queries for people who have hit this server and investigate the cache to see if it's ever been made before. Again, the cache is here to short circuit or speeds up the query lookup process to resolve a domain name to an IP address.

The DNS resolver will reach out and request what's known as the root name servers. So, the root name servers are a collective of 13 different servers distributed globally around the entire planet. It's important to note that these servers, also known as the a through the root servers, are managed by large corporate entities or academic institutions. These entities include NASA, the university of southern California, VeriSign, and us department of defense, and of course, ICANN. 

root name servers are a collective of 13 different servers distributed globally.

It is managed by 13 different clients, 12 large companies or organizations. You can study all this by following this link. root-servers.org

Now what happens is the DNS resolver reaches out to one of these root name servers at random. If one of them happened to go down, which is a very low probability, we would reach out to one of these other name servers. In this case, what's going to happen is we're going to reach out to the J name server, and we're going to ask it what the IP address is for google.com. Now we will assume that none of this information is cached to go through the end-to-end flow of resolving the IP address to the domain name. The J root server will effectively say to the DNS resolver, "I don't know exactly what that IP address is but I think I know a guy that knows a guy that might know."  So, what the J root name server responds to the DNS resolver is an IP address to the dot-com TLD. After the TLD name servers, which is the next step of the flow, is essentially a logical set of servers again distributed around the globe that correspond to the extensions that we use and see every day. These extensions are dot-com, dot-edu, and dot-org, and the list continues for almost thousands of other extensions that we see today like dot, io.biz.gov, etc.

The main resolution of the DNS root server

So, the DNS resolver gets the TLD or top-level domain from the originating google.com and what it does is propagates that query to the TLD name server for dot.com. The dot-com looks at this request and says I do not know exactly the IP address for google.com, but I think I know somebody who can get you a little closer. And what the com name server responds with is the IP address of what is known as an authoritative name server. This is typically the last step of the flow, leading us to what is known as the authoritative name server. The DNS resolver then takes this referral again and queries this IP address of the authoritative name server, asking for the IP address of google.com. Finally, the authoritative name server will scan some zone files to map the domain name to an IP address and essentially return it to the DNS resolver.

This is going to be the actual IP address that's associated with google.com. It is then and only then can the DNS resolver fulfill the initial request of the client or browser to say here is the IP address of google.com, which is the physical thing used by the browser to then communicate to the google.com servers. So fast forward getting rid of all this, we're kind of back at square one where the client wants to load google.com. But now we can do that because we have the exact address or IP of the server we are trying to communicate with, so the client sends a request as google.com servers. The server will interpret the initial query; in this case, it's a query to load the files to load google.com. The server responds with a set of files to fulfill this request, and the browser will interpret it and then load what is essentially the home page, google.com. It's important to note one important aspect of this process and that we're going to have a cache layer to store the IP address mapping for the future. This cache will hold the mapping of google.com to this 172 IP address for a specific amount of time, also known as the TTL.

The actions of the Dns server are sequential step by step

So, let's recap what we learned about DNS,

DNS is the system that translates human-readable domain names to IP addresses. Therefore, domain names will be a human-readable things like google.com,  facebook.com, and the IP addresses will be the numerical representation of uniquely assigned values that locate a particular server. The way to remember this is that an IP address is essentially the business address of a company. If you were to communicate to them, instead of sending a letter to google headquarters, you would write the address of google headquarters and get a response to remember IP addresses.

Now the overall architecture of DNS explained once more is that the client will initiate a request to load the website google.com in this case. The request gets sent to what's known as a DNS recursive resolver typically hosted by your ISP. If the IP address is not already cached on the server, it will reach out to one of 13 root name servers handled by one of those corporate entities that we looked at before. If the cache is not there, the root name server will respond with the location of what's known as a TLD name server. The TLD or top-level domain name servers correspond to the extensions like dot.com. dot-net or dot.edu. And it will respond with a referral to contact the final piece of the flow, which is the authoritative name server. Once the request to the authoritative name server goes out, we get a response that will be the actual direct IP address mapping that was initially sent to requested by the recursive resolver.

The recursive resolver will cache this lookup of the IP address and send it back to the client, and it is then and only then can the browser in the client send a request to the server's IP address and get a response back into the actual client.

 If you have any different idea please leave a comment below and we can discuss it.