When you sit at your computer, the internet seems simple. You open a browser, type the domain name, and see the website on your screen. However, underneath the Graphical User Interface (GUI) is a expansive network of software and servers known as the Domain Name System (DNS). However, what is DNS, and how does it help us view the web on our devices?

The answer to this is complex, because of the huge number of moving parts involved. You’ll find that almost every link in the chain utilizes a server. What’s more, there are techniques to help you cut down on the bottlenecks that can erode your fast page loading speeds.

For this post, we’re going to help you understand DNS in the most straightforward way we can. Let’s sum up what this article is going to cover.

How the Internet Gets a Web Page From a Server to Your Browser

As a summary, the DNS is the way we convert a readable domain name into the resultant Internet Protocol (IP) address it represents. While this seems like a simple task on the surface, it’s far from the case.

Each website lives on a server, and each server (and computer, in fact) has an IP address. The DNS is the system that maps IP addresses to domain names, so we get to enjoy user-friendly browsing. As an analogy, think of how a street name and house address is really a set of map co-ordinates. We use street addresses to simplify the longitude and latitude of a location.

When you convert an IP address into a domain name (and vice versa), this is ‘DNS resolution’. There are a number of hardware components in this chain, specifically four different types of server. Let’s discuss these next.

The 4 DNS Servers that Fetch and Load Web Pages

Every DNS request and resolution goes through four servers. Here they are, in a nutshell:

• DNS recursor. This is the ‘water carrier’ for the whole DNS. When you request a website from your browser, you tell the recursor to go and find (or ‘lookup’) the site in the DNS.
• The root nameserver. If you consider a web server that contains lots of sites, the root nameserver represents the whole. It’s the general location of the IP address.
• The Top-Level Domain (TLD) nameserver. A website will live within the root nameserver, but the TLD nameserver will dig out the final part of the IP address: The end portion of the hostname. This could be .com, .net, or myriad others.
• The authoritative nameserver. To make this complicated server simple, it’s the reference library for the IP address. This server will send the complete IP address back to the recursor, which in turn displays the site in your browser.

A DNS query goes through all of these steps, even multiple times, before the query resolves. As such, there are lots of points in the chain that can cause a query to fail – hence why we have HTTP errors.

Though, it’s worth digging into the front and back of this chain in more details. Let’s do this next.

The Difference Between the DNS Recursor and Authoritative Nameserver

You’ll understand that the recursor fetches the result of a query, and is the start of the whole DNS process. In turn, you’ll also know that the authoritative nameserver passes the result of this process back to the recursor. However, both have more differences that you’ll need to know:

• DNS recursor. This server responds to a DNS query request. It’s active in that it tracks down the DNS record along the chain. While the typical approach for a recursor is to make multiple requests to the other servers, caching can cut down on this time. We’ll talk more about this later.
• Authoritative nameserver. This server holds all of the DNS records. It’s job is to respond to a request based on the information it receives from the other servers in the chain, including the recursor. It’s this server that lets a browser display a website. Because it’s authoritative, it doesn’t need to consult other sources to validate a query – it’s a source of truth.

However, while the authoritative nameserver is the endpoint for a DNS request, it won’t always be this way. You’ll also find additional nameservers after this point depending on the request.

If a DNS query is for a subdomain (such as shop.example.com), you’ll find that there will be an extra nameserver after the authoritative one. This stores a CNAME record for the subdomain in question.

In theory, there is no limit to the number of extra nameservers a query requests. However, most of the time, there will only be one extra nameserver.

How a DNS Lookup Works

While there are four servers that process a DNS lookup and query, there are lots of steps in the chain that pass the query along and fetch results. Here’s how the lookup process works:

• You’ll type a domain name into your browser. Once you click Enter, the query heads from your browser and Operating System (OS) into the internet where the DNS recursor receives it.
• The recursor passes this query onto the root nameserver, and conducts its own query.
• The result of this query will be the TLD nameserver, which returns to the recursor.
• This time, the recursor queries the TLD nameserver, which responds with the IP address of the domain’s authoritative nameserver.
• The recursor sends another query to the authoritative nameserver, which in turn responds with the IP address for the inital domain request.

From here, the recursor sends the result of its work back to the web browser. This completes the DNS process, and the recursor can rest for a few milliseconds! The browser will then process the HTTP request in order to display the site in the browser.

There are lots of complex and labor-intensive steps (relative to what a server can achieve), and this happens billions of times a second all across the world. Even so, there are only ever three queries that take place within a lookup.

The Queries You’ll Find in a DNS Lookup

There’s a relationship within each of these queries between the DNS client and server. While these are generic terms, we’ll note any specifics within our explanations:

• Recursive query. In this query, the client will request that the DNS recursor responds either with the requested DNS record, or an error message.
• Iterative query. This query gives the recursor free license to make a ‘best guess’ with what it returns. If there’s no match for a query, the result will be a referral to a lower-level authoritative server until this ‘path’ exhausts.
• Non-recursive query. You’ll find this query will occur if a DNS record exists in cache, or the recursor has authoritative access to a record. We’ll talk about caching towards the end of the article.

In lots of cases, you’ll find that recursive and non-recursive queries are the most common. This is why you’ll see error messages, and why the lookup process can be complex.

A Primer On DNS Caching

When you deal with a non-recursive query, a record has the chance to reside in a dedicated cache for DNS records. If you know about caching, you’ll understand that it will contain files you access on a regular basis. Local apps can do this, but your site’s cache is the best example:

This will hold records for your site’s files, so that you can keep the number of HTTP requests down. The same is possible for DNS records too. This keeps the relevant records closer to your computer’s location, so that you can fetch an IP address faster than you typically would.

For web developers, a GET request is what the browser issues. With a cache, the recursor cuts out the other servers in the chain and either goes straight to the authoritative nameserver or recalls it without the need for further queries. It’s the most typical non-recursive query you can make.

In fact, you’ll find DNS caches across multiple technologies, such as your Internet Service Provider (ISP), your router, and your local computer.

You’ll find that your browser cache is the first port of call for a recursor looking for a DNS record, and as such, browsers often cache records as a default setting. Your OS will also have a DNS resolver, and this also checks its cache for a DNS record.

Again, if the OS doesn’t contain the record within its cache, it will send the query onto your ISPs recursor for processing. Both of these recursors will work with your domain’s A and NS records to try and resolve a query, before the full lookup process takes place.

Making Changes to DNS Records: ‘Propagation’

Speaking of which, you may make changes to your A, NS, or CNAME records with your registrar. In lots of cases, this will take up to 72 hours in total before all of those changes register.

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

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

The registrar often sets the TTL for your nameservers, and as such, you or anyone else won’t be able to make changes. This is why you’ll often have to wait for the propagation to finish, and why you’ll constantly check a site such as What’s My DNS? to gauge its progress:

The solution is to set your TTL as much as possible before you decide to alter your DNS records. Of course, the registrar will be responsible for your nameservers, but you’ll have done as much as you can to cut down the propagation time.

Conclusion

If you think accessing a webpage is simple, think again. For the end user, the process is simple at its core. However, under the hood it’s much more complex, and involves a plethora of additional servers.

This post has looked at the DNS – the way that the internet takes a domain name and resolve it to an IP address. From there, it can go back to the browser and render as a webpage. However, you’ll find that lots of other processes happen too, such as propagation and caching. Combined, they give us fast and (mostly) trouble-free browsing.

Do you think this article answers the question: “What is the DNS?”, and if not do you have more questions? If so, ask away in the comments section below!