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 for a more in-depth understanding of network layers. The preferred port for DNS is 53 (similar to port 80 for HTTP).

The process begins when you type 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?

Examining the DNS request headers can help answer this question. A DNS packet header contains a Transaction ID, 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://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.