When you sit at your computer, the internet seems simple. You open a browser, type in the domain name and see the website on your screen. However, beneath the Graphical User Interface (GUI) is an expansive network of software and servers known as the Domain Name System (DNS). However, what is DNS and how does it help us to view the web on our devices?
The answer to this is complex, due to the large number of moving parts involved. You will see that almost every link in the chain uses a server. Additionally, there are techniques to help you reduce bottlenecks that can erode your fast page load speeds.
For this post, we are going to help you understand DNS as directly as possible. Let’s summarize what this article will cover.
How the Internet gets a webpage from a server to your browser
In short, DNS is the way we translate a human-readable domain name into the resulting Internet Protocol (IP) address it represents. While this seems like a simple task on the surface, it is far from the case.
Every website lives on a server and every server (and computer, really) has an IP address. DNS is the system that maps IP addresses to domain names so that we can enjoy user-friendly browsing. As an analogy, think of how a street name and a house address are really a set of map coordinates. We use street addresses to simplify the longitude and latitude of a location.
When you convert an IP address to a domain name (and vice versa), this is ‘DNS resolution’. There are several hardware components in this chain, specifically four different server types. Let’s discuss this next.
The 4 DNS servers that fetch and load web pages
Each DNS request and resolution goes through four servers. Here they are, in a nutshell:
- DNS resource. This is the ‘water carrier’ for the entire DNS. When you request a site from your browser, you tell the resource to find (or ‘look up’) the site in DNS.
- The root name server. If you consider a web server that contains many sites, the root name server represents the whole. It is the general location of the IP address.
- The top-level domain name (TLD) server. A website will stay inside the root nameserver, but the TLD nameserver will extract the tail of the IP address: The tail of the hostname. It can be .com, .net or a multitude of others.
- The authoritative name server. To simplify this complicated server is the reference library for the IP address. This server will send the full IP address back to the resource, which in turn displays the website in your browser.
A DNS query goes through all these steps, even multiple times, before it is resolved. As such, there are many points in the chain that can cause a query to fail – so we have HTTP errors.
However, it’s worth investigating the front and back of this chain in more detail. Let’s do that next.
The difference between Resource DNS and authoritative name server
You will understand that the resource fetches the result of a query and is the beginning of the entire DNS process. In turn, you will also know that the authoritative name server passes the result of this process back to the resource. However, they both have more differences that you need to know:
- DNS resource. This server responds to a DNS query request. It is active because it tracks the DNS record along the chain. While the typical approach for a resource is to make multiple requests to other servers, caching can reduce this time. We’ll talk more about that later.
- Authoritative name server. This server contains all DNS records. Your job is to respond to a request based on information received from the other servers in the chain, including the resource. It is this server that allows a browser to 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 name server is the endpoint for a DNS request, this is not always the case. You will also find additional nameservers after this point, depending on the request.
If a DNS query is for a subdomain (like shop.example.com), you’ll find that there’s an extra nameserver after the authoritative one. This stores a CNAME registration 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 many steps in the chain that pass the query and get results. Here’s how the search process works:
- You will enter a domain name in your browser. As soon as you click Log inthe query goes from your browser and operating system (OS) to the Internet, where the DNS resource receives it.
- The resourcer passes this query to the root name server and conducts its own query.
- The result of this query will be the TLD nameserver, which will return to the resource.
- This time, the resource queries the TLD nameserver, which responds with the IP address of the domain’s authoritative nameserver.
- The resourcer sends another query to the authoritative name server, which in turn responds with the IP address of the initial domain request.
From here, the resourcer sends the result of its work back to the web browser. This completes the DNS process and the resource can rest for a few milliseconds! The browser will process the HTTP request to display the website in the browser.
There are many complex and laborious steps (relative to what a server can achieve), and this happens billions of times per second all over the world. Even so, there are only three queries that occur in a search.
The queries you will find in a DNS lookup
There is a relationship within each of these queries between the DNS client and the server. While these are generic terms, we’ll note any details in our explanations:
- Recursive query. In this query, the client will ask the DNS resource to respond with the requested DNS record or an error message.
- Iterative query. This query gives the resource a free license to make a ‘best guess’ with what it returns. If there is no match for a query, the result will be a reference to a lower-level authoritative server until this ‘path’ is exhausted.
- Non-recursive query. You will see that this query will occur if there is a DNS record in the cache or if the resourcer has authoritative access to a record. We’ll talk about caching at the end of the article.
In many cases, you will find that recursive and non-recursive queries are the most common. That’s why you’ll see error messages and why the search process can be complex.
A primer on DNS caching
When you handle a non-recursive query, a record has a chance to reside in a dedicated cache for DNS records. If you are familiar with the cache, you will understand that it will contain files that you access regularly. Local apps can do this, but your site’s cache is the best example:
This will keep records of your website files so you can keep the number of HTTP requests low. The same is possible for DNS records as well. This keeps the relevant logs closer to your computer’s location, so you can look up an IP address faster than you normally would.
For web developers, a
GET request is what the browser issues. With a cache, the resourcer cuts off the other servers in the chain and goes straight to the authoritative name server or retrieves it without the need for further queries. It’s the most typical non-recursive query you can do.
In fact, you will find DNS caches in many technologies, such as your Internet Service Provider (ISP), your router, and your local computer.
You’ll find that your browser’s cache is the first port of call for a resource looking for a DNS record, and as such, browsers often cache records as a default setting. Your operating system will also have a DNS resolver, and this also checks your cache for a DNS record.
Again, if the operating system does not contain the record in its cache, it will send the query to the ISPs resource for processing. Both features will work with your domain ONE and NS records to try to resolve a query, before the full search process takes place.
Making changes to DNS records: ‘Propagation’
By the way, you can make changes to your ONE, NSor CNAME records with your registrar. In many cases, it will take up to 72 hours in total before all these changes are recorded.
This is DNS propagation, and the time it takes to complete depends on several factors – namely the TTL (Time To Live) value of an associated record:
In short, this determines how quickly 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 usually sets the TTL for its nameservers and as such you or anyone else will not be able to make changes. This is why you will often have to wait for the propagation to finish and why you will constantly check a site like What is my DNS? to assess your progress:
The solution is to set your TTL as much as possible before deciding to change your DNS records. Of course, the registrar will be responsible for your nameservers, but you will have done your best to reduce 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 is much more complex and involves a multitude of additional servers.
This post looked at DNS – the way the internet takes a domain name and resolves it to an IP address. From there, it can go back to the browser and render as a web page. However, you will find that many other processes take place as well, such as seeding and caching. Combined, they give us fast and (mostly) trouble-free browsing.
Do you think this article answers the question, “What is DNS?” and if not, do you have more questions? If so, ask in the comments section below!