Want to know how much website downtime costs, and the impact it can have on your business?
Find out everything you need to know in our new uptime monitoring whitepaper 2021
The Domain Name System, DNS for short, is one of the most important protocols on the internet, and yet relatively few people understand its purpose. DNS is a protocol which governs how computers exchange data online. Its purpose, simply stated, is to match names with numbers, helping to convert memorable domain names (such as statuscake.com), into an IP address (such as 8.8.8.8 for Google.com) that your browser can use.
DNS is essentially a map or a phone book of the internet. As each device and website connected to a network has its own IP address, without DNS we would be forced to keep our own records of which domain names match which IP addresses, which would make the internet much more difficult to use!
The purpose that DNS serves, therefore, is relatively straightforward, but the process itself is not, particularly as there are billions of active IP addresses in use, and billions of DNS requests occurring at any given time.
In this article we will aim to explain how the Domain Name System works, explaining each step from the first query to the moment a webpage loads on your browser.
How does DNS Work?
To the end-user, DNS lookup appears to occur instantaneously, requiring no more than the domain name and a tap of the enter key. However, there is plenty of heavy lifting occurring behind the scenes, with the request, in most cases, passing between four servers before finally matching the domain name with the IP address and loading the webpage.
Here are the four servers involved in the DNS protocol:
DNS Recursor – The main function of the DNS Recursor is to receive the initial query and to pass it on to the relevant server.
Root Nameserver – The Root Nameserver takes the first step in resolving the domain name entered in the initial query into an IP address.
TLD Name Server – The Top Level Domain Server (TLD) is where the last portion of an address (e.g. .com) is hosted.
Authoritative Nameserver – In the last step in the process, the Authoritative Nameserver returns the requested hostname (if it has access to it), back to the DNS Recursor resulting in the webpage being loaded.
DNS Recursor
Every DNS request begins with a query. For example, when you enter statuscake.com into your web-browser your browser proceeds to send a query over the internet to find the matching IP address for that domain name. The first step in this process is for the browser to query the DNS Recursor (also known as a recursive resolver) which can be operated by your ISP, a wireless provider, or a third-party. In this first step, the DNS Recursor acts as a middle-man, connecting your query with the relevant IP address to answer the question of which IP address is associated with the initial query.
Root Nameserver
The Root Nameserver is the first type of DNS server that the DNS Recursor talks to on the road to resolving your query. There are 13 sets of root servers in over 300 locations across the globe, and each one holds DNS information about top-level domains such as .com. There are also thousands of servers supporting the Root Nameservers, located according to where internet demand is the highest. The Root Nameserver helps to translate the original text-based query into a language, such as IP addresses, which computers can understand.
TLD Nameserver
The Top Level Domain (TLD) Nameserver provides the next piece in the puzzle by answering the initial query with the IP address of the domain’s name server. Similar to the Root Nameservers, the TLD Nameservers have 4-13 nameservers across many different locations. The main purpose of the TLD is to store the address information for second-level domains (such as statuscake.com).
Authoritative Nameserver
The Authoritative Nameserver is the final step in the DNS process. In this step, the Authoritative Nameserver is able to match an IP address with the requested hostname and returns it to the DNS Recursor. Armed with the matching IP address for the initial domain name query, the DNS Recursor is able to tell your browser what the requested IP address is. Finally, your web browser uses the newly learned IP address to reach the website, and to load the webpage you initially requested!
There are exceptions, deviations, and many layers of extra detail to the DNS process, including caching and non-recursive queries. However, the fundamental process is that which we have outlined in this article, where the initial query proceeds through four servers – DNS Recursor; Root Nameserver; TLD Name Server; Authoritative Nameserver – before the matching IP address and domain name are returned to your browser.
If you would like to monitor and enhance the performance of your website, StatusCake provides a suite of website performance monitoring tools which are easy to set-up and use, and provide you with invaluable insights into how your website’s performance is impacting your customers’ experiences.
StatusCake Team
Share this
More from StatusCake
Alerting Is a Socio-Technical System
3 min read In the previous posts, we’ve looked at how alert noise emerges from design decisions, why notification lists fail to create accountability, and why alerts only work when they’re designed around a clear outcome. Taken together, these ideas point to a broader conclusion. That alerting is not just a technical system, it’s a socio-technical one. Alerting
James Barnes
February 25, 2026
Designing Alerts for Action
3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams
James Barnes
February 18, 2026
A Notification List Is Not a Team
3 min read In the previous post, we looked at how alert noise is rarely accidental. It’s usually the result of sensible decisions layered over time, until responsibility becomes diffuse and response slows. One of the most persistent assumptions behind this pattern is simple. If enough people are notified, someone will take responsibility. After more than fourteen years
James Barnes
February 11, 2026
Alert Noise Isn’t an Accident — It’s a Design Decision
3 min read In a previous post, The Incident Checklist: Reducing Cognitive Load When It Matters Most, we explored how incidents stop being purely technical problems and become human ones. These are moments where decision-making under pressure and cognitive load matter more than perfect root cause analysis. When systems don’t support people clearly in those moments, teams compensate.
James Barnes
February 4, 2026
The Incident Checklist: Reducing Cognitive Load When It Matters Most
4 min read In the previous post, we looked at what happens after detection; when incidents stop being purely technical problems and become human ones, with cognitive load as the real constraint. This post assumes that context. The question here is simpler and more practical. What actually helps teams think clearly and act well once things are already
James Barnes
January 28, 2026
When Things Go Wrong, Systems Should Help Humans — Not Fight Them
3 min read In the previous post, we explored how AI accelerates delivery and compresses the time between change and user impact. As velocity increases, knowing that something has gone wrong before users do becomes a critical capability. But detection is only the beginning. Once alerts fire and dashboards light up, humans still have to interpret what’s happening,
James Barnes
January 21, 2026