# Demystifying DNS: Understanding Domain Name Resolution

# Introduction

The route to reach a server hosted on the public internet is through its public IP address. If you know the IP address of a server, you can access it directly. However, there are two main drawbacks to this approach:

1. **Hard to Operate**: Remembering an IP address can be challenging, and they are subject to change. Common users who work with IP addresses often find it difficult to remember them and cope with frequently changing addresses. It’s easier to remember google.com than `142.250.182.14`.
    
2. **Not Scalable**: High-demand servers, like Google, need to have hundreds of servers located around the globe. The Google server that caters to a user in Australia does not serve a user in North America, meaning there is not just one IP address.
    

To address these problems, the Domain Name System (DNS) is utilized. In this article, we will take a detailed look at how DNS resolution occurs under the hood.

# DNS Resolution Under the hood

DNS is a protocol built on top of UDP, a layer 4 protocol. You may refer to the [first article in this series](https://oxyprogrammer.com/navigating-networking-layers-the-journey-of-data-through-tcp) for a more in-depth understanding of network layers. The preferred port for DNS is 53 (similar to port 80 for HTTP).

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731218610142/937dc599-e4cd-469d-b658-8639a220afd3.png align="center")

The process begins when you type [google.com](http://google.com) into your browser's address bar. The following steps will occur (refer diagram above):

1. **Hit the Resolver**: If the browser does not have the IP address of `google.com` in its local cache, it will send a request to the resolver server for the IP address of `google.com`. This is a sync request. Resolver server addresses are configured within your network. Once you connect to a network that has internet access, the resolver is recognized by your machine through your ISP.
    
2. **Resolver Hits Root**: The resolver then queries a DNS root server. The address of the local root server is known to the resolver. There are over 13 root servers globally, ensuring high availability and reduced latency. The root server will provide the address of the top-level domain server (TLD), such as “`.com`.”
    
3. **Resolver Hits the TLD**: Next, the resolver contacts the TLD server, which, in this case, will be the `.com` server. This TLD server has records for all .com domain name registries. Like the root servers, TLD servers are also replicated worldwide. The TLD server returns the address of an authoritative name server.
    
4. **Authoritative Name Server Response**: The authoritative name servers return the IP address of the second-level domain that is closest to the user. This is also where load balancing occurs; for example, `google.com` will return different IP addresses of replicated servers in response to different requests to distribute the load effectively.
    

# DNS packet header anatomy

A question that arises is: how does the resolver distinguish between the different requests that are coming in?

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731218650674/8ed4ee2b-33f2-46e7-a9ba-f2fbb95267ee.png align="center")

Examining the DNS request headers can help answer this question. A DNS packet header contains a <mark>Transaction ID</mark>, which assists in tracking the request. Additionally, it is worth noting that the resolver maintains a local cache to avoid contacting the root server for each request.

# Further Reading

* [https://www.usenix.org/system/files/sec20-zheng.pdf](https://www.usenix.org/system/files/sec20-zheng.pdf)
    
* [https://datatracker.ietf.org/doc/html/rfc1035](https://datatracker.ietf.org/doc/html/rfc1035) 
    

## Conclusion

It is fascinating to realize how many processes occur behind the scenes when we attempt to access a domain name through our browser. We explored the various steps that constitute the DNS resolution process. We also noted that the DNS request is synchronous and built on top of UDP, ensuring fast communication.