Because of the TCP/IP model, a browser requires the target server’s IP address to request resources.
For us, it is nearly impossible to remember numbers in an IP. However, it is straightforward to identify a domain name.
But how a browser acquires the IP address from a domain?
The process is domain name resolution.
Root DNS servers
As of today, 13 root DNS servers serve the process for us.
- Each root DNS server maintains a list of IP addresses of top-level DNS servers.
- By visiting a top-level DNS server, the system receives the target authoritative DNS server’s IP address.
- Finally, the authoritative DNS server returns the IP address of the domain we are looking for.
Take www.medium.com as an example:
- The root DNS server returns the IP address of the top-level DNS server maintaining the
.comdomains. - Then, by visiting the
.comtop-level DNS server, the system finds themedium.comauthoritative DNS server's IP address. - Next, the
medium.comauthoritative DNS server returns the IP address ofwww.medium.com. - Lastly, our browser can send a request to the server for the homepage of the Medium site.
Public DNS servers
When billions of people visiting the web every day, 13 root servers are not adequate to serve all.
Some companies provide public DNS servers (aka non-authoritative DNS servers), such as 8.8.8.8 from Google and 1.1.1.1 from Cloudflare, to help the process runs smoothly.
Before visiting a root DNS server, our operating system actually looks for the domain in public DNS servers.
Local DNS cache
To speed up the process, our browsers and the operating system cache the IP addresses locally to save you a trip to the internet.
When you enter a domain in a browser, the browser checks its DNS cache.
If the record is not in the browser DNS cache, your operating system jumps in and looks at the OS’s DNS cache.
Lastly, the hosts file on your hard drive is checked before reaching out to the public DNS servers.
Put all together
So, let’s put them together. Here is the entire process of the domain name resolution.
Pros and cons of the process
Using a domain enables so much flexibility to our network system.
Thanks to the domain name resolution, your users can still visit your site with the same domain when you change to a new server. If we need to notify every visitor of the updated IP address, that’s a lot of work.
Another well-known use case is implementing a load balancing feature based on domain names.
Each domain name can return a list of IP addresses to the client, meaning multiple servers are behind the scene. By then, the browser can send requests to each IP sequentially.
Based on different criteria, a server can return selected IP addresses to the browser, such as locations, server health, etc.
The evil side? Your browser could receive an unexpected IP.
To a browser, the process is simple. It sends a domain name and receives IP addresses. And it has to trust the return.
Here come the problems.
Nodes in-between can either return no IP address or the wrong one, leading you to a phishing website.
Fortunately, it doesn’t happen often.
Takeaways
- The domain name resolution process is browser DNS cache → OS cache → hosts → public DNS servers → root DNS server → top-level DNS server → authoritative DNS server.
- Using a domain name makes our life more comfortable. At the same time, it brings new security problems.
