What is DNS? & How DNS works

What is DNS?

Think of the Domain Name System (DNS) as the Internet’s 411 service. We humans find it easier to navigate the web using domain names like nytimes.com or espn.com, unlike our web browser buddies who prefer to mingle via Internet Protocol (IP) addresses. DNS comes to our rescue by converting these domain names into IP addresses, enabling browsers to access various Internet resources.

Each gadget hooked up to the Internet gets a unique IP address that acts like its online postal code, guiding other computers to its digital doorstep. Thanks to the DNS servers, we don’t need to rack our brains trying to remember intricate IP addresses like 192.168.1.1 (IPv4) or the newer and certainly more brain-twisting alphanumeric IPs such as 2400:cb00:2048:1::c629:d7a2 (IPv6). Now, isn’t that a relief?

How does DNS work?

Just like a house has a unique address for locating it, every device connected to the internet has a unique IP address. So, when you’re trying to load a particular webpage, say www.sample.com on your browser, some tech magic needs to happen to translate that domain name into a machine-friendly IP address.

Ever wondered what’s going on with your machine while you’re impatiently drumming your fingers, waiting for a webpage to load? Well, DNS resolution is hard at work behind the scenes. The ‘who’s who’ and ‘where’s where’ of the internet!

Getting into the thick of it, understanding how DNS resolution works involves diving deep into the fascinating sea of hardware component communications and the DNS query’s. The good news? Your computer knows the route and doesn’t need much from you except the name of the webpage you want to explore. Kind of like playing fetch, but for internet pages!

The different 4 DNS servers involved in loading a webpage

DNS recursor

Imagine the DNS recursor as a librarian, hunting for a specific book in the vast library – upon receiving a request from a user. This librarian is none other than the DNS recursor server, a hardworking hero, that behind the scenes makes sure that every web browsing quest ends in a user finds the website he is looking for.

When users embark on an internet expedition via their web browsers, and enters a website in their webbrowser, it gets delegates to the a DNS recursor server. The server then shoulders the gargantuan task of carrying out the requests to fulfill the user’s original DNS query. Some would say its a digital Sherlock Holmes if you will!. We owe our smooth internet browsing to these unsung bibliophilic heroes of the digital world!

Root nameserver

The root server plays a crucial role in converting human-friendly domain names into IP addresses. It can be compared to an index in a library that directs you to specific bookshelves. In essence, it serves as a central reference point for locating more detailed information.

TLD nameserver

The top-level domain server (TLD) is analogous to a dedicated section of books in a library. Similar to how the TLD server is responsible for hosting the final portion of a hostname (like “com” in example.com), this nameserver plays a crucial role in the quest for a specific IP address. Just like you would browse through a specific rack of books to find the one you need, the TLD server serves as the next step in the search process.

Authoritative nameserver

Think of the final nameserver as a reference bookshelf, where each book represents a specific name and its meaning. This authoritative nameserver acts as the last point in the nameserver query process. If the authoritative nameserver has the requested record, it will send the IP address associated with the hostname back to the DNS Recursor (the librarian) who initiated the request. This ensures a smooth and accurate translation of domain names to IP addresses.

The difference between an authoritative DNS server and a recursive DNS resolver

Both ideas pertain to servers (clusters of servers) which play vital roles in the DNS structure, yet each performs dissimilar roles and exists at different stages within the DNS query pipeline. A practical way to distinguish between these roles is to consider the recursive resolver at the outset of the DNS query and the authoritative nameserver at its conclusion.

Recursive DNS resolver

The recursive resolver is the digital component that handles a client’s recursive request, dedicating its resources and time to locate the DNS record. This is achieved by initiating a sequence of requests until it contacts the authoritative DNS nameserver pertaining to the requested record. However, if the record is not found, it will either timeout or return an error message. Fortunately, recursive DNS resolvers can bypass the need for multiple requests to locate the required records for a client response. This is possible through a data persistence strategy known as caching, which can quicken the process by presenting the requested resource record in the early stages of the DNS lookup.

Authoritative DNS server

In simple terms, an authoritative Domain Name System (DNS) server is the server which holds and manages DNS resource records. This server is the final component in the DNS lookup sequence, responsible for answering with the queried resource record. This process enables the web browser making the request to obtain the required IP address for accessing a webpage or other online resources. An authoritative nameserver has the ability to respond to queries using its own data, eliminating the need to consult another source – it serves as the ultimate source of truth for certain DNS records.

It’s important to note that in cases where a subdomain is being queried, such as foo.example.com or blog.cloudflare.com, an additional nameserver enters the sequence following the authoritative nameserver. This subsequent nameserver is charged with maintaining the CNAME record of the subdomain.

What diffrent steps are in a DNS lookup?

The next question is then: How DNS work? In most scenarios, the primary function of DNS is transforming domain names into the corresponding IP addresses. To understand this mechanism better, it’s beneficial to trace the journey of a DNS lookup from the point of origin – a web browser, through the DNS lookup procedure, and back. So let’s look at this process step by step.

It is important to note that, commonly, the data from a DNS lookup will be stored in a cache, either locally in the computing device initiating the query, or distantly within the DNS infrastructure itself. A full DNS lookup typically comprises of 8 steps. When the DNS information is cached, certain steps from the lookup process are bypassed, which accelerates the entire process. The example below provides a detailed overview of all these 8 steps, assuming that no information is cached.

The ten step process of a DNS Lookup

1) A user enters ‘example.com’ into the search bar of a browser, which then sends a request into the Internet, received by a DNS recursive resolver.

2) The resolver then queries a DNS root nameserver.

3) The core server in turn provides the Resolver with the address of a Top-Level-Domain (TLD) DNS server (like .com or .net), which contains data for its own domains. For instance, if we are searching for example.com, our demand is directed towards the .com TLD.

4) The resolver then makes a request to the .com TLD.

5) The Top Level Domain (TLD) server then provides the Internet Protocol (IP) address associated with the domain’s nameserver; in this case it would be example.com.

6) The recursive resolver then sends a query to the specific nameserver of the domain.

7) The IP address for example.com is then returned to the resolver from the nameserver.

8) The DNS resolver, then returns the IP-address to the browser

9) The browser makes a HTTP request to the IP address.

10) The server at the defined IP sends back the webpage to be displayed in the user’s browser

What is a DNS resolver?

The DNS resolver serves as the initial checkpoint in the DNS lookup, tasked with managing requests from clients initiating the process. The resolver instigates a series of inquiries that eventually interpret a URL into the requisite IP address.

A common uncached DNS lookup will entail both recursive and iterative queries.

Recognizing the difference between a recursive DNS query and a recursive DNS resolver is integral. The query denotes the request made to a DNS resolver necessitating the query’s resolution. In contrast, a DNS recursive resolver corresponds to the computer accepting a recursive query, and it bears the responsibility of processing the response through making the appropriate requests.

The types of DNS queries

In every standard DNS lookup, three central query models are deployed. Leveraging these in a coordinated sequence can streamline the DNS resolution process and minimize the extent of the data journey. Ideally, data from a previous record will already be cached, empowering a DNS name server to process a non-recursive query.

3 types of DNS queries

1) Recursive Query

In a recursive query, a client asks a DNS server (usually a DNS recursive resolver) to reply back either with the requested resource record or with an error message if the resolver fails to locate the record. This demand for a comprehensive response is key to understanding a recursive query, and it puts the onus on the DNS server to provide a complete answer or reason for its inability.

2) Iterative query

In an iterative query scenario, the DNS client permits a DNS server to provide the finest answer it can. If the DNS server inquired does not have an exact match for the query name, it will return a referral to a DNS server that holds authority for a lower level of the domain namespace. The DNS client will then direct a query to the referred address. This process repeats with subsequent DNS servers along the query chain until either an error transpires or a timeout is encountered.

3) Non-recursive query

Querying in a non-recursive manner usually occurs when a DNS resolver client inquires to a DNS server about a record that is either authoritative or exists within its cache. Generally, DNS servers store DNS records in a cache to minimize additional bandwidth usage and relieve stress on upstream servers. This information is vital because it provides insights into the functioning of your domain’s DNS server, enabling you to optimize your websites for improved accessibility and better SEO ranking.

What is DNS caching? Where does DNS caching occur?

Caching serves the purpose of storing data temporarily in a location that enhances performance, reliability, and efficiency of data requests. DNS caching, specifically, is a strategy where data is stored nearer to the client making the request, therefore enabling the DNS query to be settled faster. This strategy effectively bypasses the need for additional queries further along the DNS lookup chain, ensuring quicker loading times and decreased consumption of bandwidth and CPU. The DNS data may be cached in several locations, all of which will keep the data for a predetermined amount of time as dictated by a time-to-live (TTL).

Browser DNS caching

Today’s webbrowsers are inherently programmed to store DNS records for a specified duration. The motive behind this is to reduce the number of processing steps involved in checking the cache and initiating the appropriate requests to an IP address. Whenever a demand is made for a DNS record, the browser’s cache becomes the first point of information retrieval.

In Google Chrome, you can examine the condition of your DNS cache by directing your browser to chrome://net-internals/#dns. This will show you various details about your DNS cache, offering you insights into its operational status and performance. It can be a valuable tool in understanding the technical aspects of your web navigation and site optimization. It offers concrete data that can help guide your SEO efforts, particularly for a blog about domains.

Operating system (OS) level DNS caching

The second phase of local action in DNS query is operated through an OS level DNS resolver. This element, often known as “stub resolver” or DNS client, manages these queries within your operating system. It initially checks its cache for the record when a request is made by an application. If the necessary record isn’t found, then the DNS client dispatches a recursive DNS query to a DNS recursive resolver integrated with the Internet service provider (ISP).

Upon receiving a DNS query, the recursive resolver in the ISP also verifies if the translation of host-to-IP-address being requested is already stored in its local persistence area.

This ISP-integrated recursive resolver has additional functionality, which is influenced by the types of the records it retains in its cache

1. If the resolver lacks the A records yet possesses the NS records for the authoritative nameservers, it will bypass numerous steps and directly question those nameservers. This detour avoids root and .com nameservers look-ups (like in our example.com search) facilitating a quicker DNS query resolution.
2. If the resolver lacks NS records, it dispatches a query to the Top-Level Domain (TLD) servers, in this case .com, bypassing the root server.
3. In case the resolver lacks the necessary records it gets redirected to the TLD servers, its next action is then to send a query to the root servers.

Who should you use as your DNS provider?

There are plethora of Domain Name System (DNS) providers available in today’s digital era. These providers play a critical role in making the internet user-friendly and accessible; they connect domain names with their respective IP addresses, thereby ensuring seamless navigation online. Some of these providers include Google DNS, Cloudflare, OpenDNS, and Quad9, each offering different features such as security filters, privacy protection, and fast resolving speed. Multiple providers create a competitive environment, pushing each to continuously improve and innovate their services. This abundance of DNS providers allows users to choose the one that best fits their needs and requirements. But In the end its often a matter of preferences what DNS provider you use – we personally have been using CloudFlare’s free DNS plans for nearly 10 years – and can say nothing but good things about it