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.
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.
Every DNS request and resolution goes through four servers. Here they are, in a nutshell:
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.
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:
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.
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:
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.
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:
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.
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.
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.
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!
Are you on the look out for Google Analytics alternatives? Google Analytics has dominated the…
Are you on the hunt for cPanel alternatives? cPanel is the web server control panel…
New to Webflow and not sure where to start? This step-by-step guide will show you…
Are you in the market for a forum software to get your online community off…