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
AI Didn’t Kill the SDLC. It Made It Harder to See
10 min read Whilst AI has compressed the visible stages of software delivery; requirements, validation, review and release discipline have not disappeared. They have been pushed into automation, runtime and governance. The real risk is not that the lifecycle is dead, but that organisations start acting as if accountability died with it. There is a now-familiar story about
James Barnes
April 2, 2026
When Code Becomes Cheap: The New Reliability Constraint in Software Engineering
4 min read How AI Is Shifting Software Engineering’s Primary Constraint For most of the history of software engineering, the primary constraint was production. Code was expensive, skilled engineers were scarce, and shipping features required concentrated human effort. Velocity was limited by how fast people could reason, implement, test, and deploy. That constraint shaped everything from team size,
James Barnes
March 25, 2026
Buy vs Build in the Age of AI (Part 3)
5 min read Autonomous Code, Trust Boundaries, and Why Governance Now Matters More Than Ever In Part 1, we looked at how AI has reduced the cost of building monitoring tools. Then in Part 2, we explored the operational and economic burden of owning them. Now we need to talk about something deeper. Because the real shift isn’t
James Barnes
March 18, 2026
Buy vs Build in the Age of AI (Part 2)
6 min read The Real Cost of Owning Monitoring Isn’t Code — It’s Everything Else In Part 1, we explored how AI has dramatically reduced the cost of building monitoring tooling. That much is clear. You can scaffold uptime checks quickly, generate alert logic in minutes, and set-up dashboards faster than most teams used to schedule the kickoff
James Barnes
March 11, 2026
Buy vs Build in the Age of AI (Part 1)
5 min read AI Has Made Building Monitoring Easy. It Hasn’t Made Owning It Any Easier. A few months ago, I spoke to an engineering manager who proudly told me they had rebuilt their monitoring stack over a long weekend. They’d used AI to scaffold synthetic checks. They’d generated alert logic with dynamic thresholds. They’d then wired everything
James Barnes
March 4, 2026
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