How the Internet delivers a web page from a server to your browser

You could say that DNS is a way of translating a human-readable domain name into the resulting Internet Protocol (IP) address it represents. Although this may seem like a simple task at first glance, it is anything but.

Every website lives on a server, and every server (and computer, for that matter) has an IP address. DNS is the system that maps IP addresses to domain names, so we can enjoy user-friendly browsing. As an analogy, think of how a street name and house number are really just a set of coordinates on a map. We use street addresses to make a location's longitude and latitude easier to work with.

A map screen showing a physical address, latitude, and longitude.

When you convert an IP address into a domain name (and vice versa), that's “DNS resolution.” There are several hardware components in this chain, specifically four different types of servers. Let's discuss them next.

4 DNS servers that retrieve and load web pages

Every DNS query and resolution passes through four servers. Here they are, in brief:

DNS resolver.

This is the “water carrier” for all of DNS. When you request a website from your browser, you're telling the resolver to go and find (or “look up”) the site in DNS.

Root name server.

If you think of a web server as containing many websites, the root name server is the whole thing. It is the general location of the IP address.

Top-level domain (TLD) name server.

A website lives on a root name server, but the TLD name server digs up the last part of the IP address: the final part of the hostname. This could be .com, .net, or any of many others.

Authoritative name server.

To make this complex server simple, think of it as a reference library for the IP address. This server sends the full IP address to the resolver, which then displays the site in your browser.
A DNS query goes through all these stages, sometimes more than once, before resolving the request. So there are plenty of points in the chain where a request can fail, which is why we have HTTP errors.

Still, it's worth digging into the front and back ends of this chain in more detail. Let's do that next.

The difference between a DNS resolver and an authoritative name server

You'll understand that the resolver retrieves the result of a query and is the starting point for the whole DNS process. In turn, you'll also know that the authoritative name server passes the result of this process back to the resolver. However, there are more differences between the two that you need to know:

DNS resolver. This server responds to a DNS query request. It is active in that it follows the DNS record along the chain. Although the typical approach for a resolver is to make multiple requests to other servers, caching can cut down on this time. We'll talk about that later.

Authoritative name server. This server holds all the DNS records. Its job is to answer a query based on the information it receives from other servers in the chain, including the resolver. This is the server that lets the browser display a website. Because it is authoritative, it doesn't need to consult other sources to verify a query—it's the source of truth.
However, although the authoritative name server is the endpoint for a DNS query, that isn't always the end of the story. Depending on the query, you may find additional name servers after this point.

If a DNS query is for a subdomain (for example, shop.example.com), you'll find an additional server after the authoritative name server. This holds the CNAME record for the subdomain in question.

In theory, there is no limit to the number of additional name servers a query can request. However, in most cases there will be only one additional name server.

How DNS lookup works

Although there are four servers that handle DNS lookup and queries, the chain involves many steps that pass along the request and retrieve the results. Here's how the lookup process works:

  • You enter a domain name in your browser. As soon as you press Enter, the request from your browser and operating system (OS) is sent to the internet, where the DNS resolver receives it.
  • The resolver passes this request to the root name server and makes its own query.
  • The result of this query is the TLD name server, which is returned to the resolver.
  • This time, the resolver queries the TLD name server, which responds with the IP address of the domain's authoritative name server.
  • The resolver sends another query to the authoritative name server, which in turn responds with the IP address for the original domain request.
  • From there, the resolver sends the result of its work back to the web browser. That wraps up the DNS process, and the resolver can take a break for a few milliseconds!
  • The browser then processes an HTTP request to display the site in the browser.

There are many complex and time-consuming steps (relative to what a server can accomplish), and this happens billions of times a second around the world. Despite that, only three queries are made during the lookup.

The queries you'll encounter during a DNS lookup

Each of these queries involves a connection between a DNS client and a server. Although these are general terms, we'll point out any specifics in our explanations:

Recursive query.

In this query, the client requires the DNS resolver to respond with either the requested DNS record or an error message.

Iterative query.

This query gives the resolver a free license to “guess” what it returns. If there is no match for the query, the result is a referral to a lower-level authoritative server, until this “path” is exhausted.

Non-recursive query.

You'll find that this query occurs if the DNS record exists in the cache or the resolver has authoritative access to the record. We'll talk about caching toward the end of the article.

In many cases, you'll find that recursive and non-recursive queries are the most common. That's why you'll see error messages and why the lookup process can be complex.

When you're dealing with a non-recursive query, the record may be in a dedicated cache for DNS records. If you know about caching, you'll understand that it holds files you access regularly. Local applications can do this, but the best example is your website cache.

W3 Total Cache plugin in the WordPress dashboard

This lets you store records for your website files so you can reduce the number of HTTP requests. The same is possible with DNS records. This keeps relevant records closer to your computer's location, so you can get an IP address faster than usual.

For web developers, a GET request is what the browser issues. When using a cache, the resolver bypasses the other servers in the chain and either goes straight to the authoritative name server or calls it without needing any further queries. This is the most typical non-recursive query you can make.

In fact, you'll find DNS caches in several technologies, such as your Internet Service Provider (ISP), your router, and your local computer.

The Brave browser showing the number of cached files in memory.

You'll find that your browser cache is the resolver's first port of call when looking for a DNS record, which is why browsers often cache records by default. Your OS also has a DNS resolver, and it too checks its cache for a DNS record.

Again, if the OS doesn't have the record in its cache, it will send a request to your ISP's resolver to process. Both of these resolvers work with your domain's A and NS records to try to resolve the query before the full lookup process takes place.

Making changes to DNS records: “propagation”

Speaking of which, you can make changes to your A, NS, or CNAME records at your registrar. In many cases, it can take up to 72 hours before all these changes are registered.

This is DNS propagation, and how long it takes to complete depends on a number of factors, namely the Time to Live (TTL) value for the associated record:

Registrar records showing TTL values in seconds.

In short, this determines how quickly a change takes effect for a specific DNS record. A typical TTL is around four hours, and the higher the value, the longer propagation will take.

Conclusion

If you think accessing a web page is simple, think again. For the end user, the process is inherently simple. But behind the scenes, it's much more complicated and involves a lot of extra servers.