What is DNS?

Last updated:

What is DNS?

What is DNS?

The Domain Name System (DNS) functions as the Internet’s equivalent of a telephone directory. When humans seek information online, they use domain names like nytimes.com or espn.com. Meanwhile, web browsers communicate via Internet Protocol (IP) addresses. DNS performs the task of converting domain names into IP addresses, enabling browsers to load online resources.

Each device that’s connected to the Internet possesses a distinct IP address, employed by other machines to locate that device. DNS servers eliminate the necessity for humans to commit IP addresses to memory, whether it’s the simpler 192.168.1.1 (in IPv4) or the more intricate and alphanumeric 2400:cb00:2048:1::c629:d7a2 (in IPv6).

How Does DNS Function?

DNS resolution is the procedure of transforming a hostname (e.g., www.example.com) into a computer-readable IP address (e.g., 192.168.1.1). Each device on the Internet is assigned an IP address, which is crucial for pinpointing the correct internet-connected device—similar to how a street address is employed to locate a specific residence. When a user intends to load a webpage, there’s a need to translate what the user inputs into their web browser (e.g., example.com) into the machine-friendly address essential for locating the corresponding example.com webpage.

To grasp the process of DNS resolution, it’s essential to familiarize yourself with the various hardware components that a DNS query traverses. For the web browser, the DNS lookup transpires “behind the scenes” and doesn’t necessitate any action from the user’s computer aside from the initial request.

In the process of loading a webpage, four DNS servers play distinct roles:

  • DNS Recursor - Imagine the DNS recursor as a librarian tasked with locating a particular book within a vast library. Acting as a server, the DNS recursor receives queries from client machines via applications like web browsers. Typically, it goes beyond this initial query to make further requests in order to fulfill the client’s DNS query.

  • Root Nameserver - The root server serves as the foremost step in converting human-readable host names into IP addresses, essentially resolving them. It can be likened to an index in a library, directing toward various sections of books. In most cases, it acts as a reference to more specialized locations.

  • TLD Nameserver - Analogous to a designated bookshelf in a library, the top-level domain server (TLD) represents a specific collection. This server constitutes the subsequent stage in the pursuit of a specific IP address and holds the concluding portion of a hostname. For instance, in “example.com,” the TLD server is “com.”

  • Authoritative Nameserver - Visualize the authoritative nameserver as a dictionary residing on a bookshelf, enabling the translation of a particular name into its definition. The authoritative nameserver marks the final destination within the nameserver inquiry. Should the authoritative nameserver possess the requested record, it responds to the DNS Recursor (the librarian) that initiated the initial request with the IP address associated with the sought-after hostname.

How does an authoritative DNS server differ from a recursive DNS resolver?

While both terms relate to server clusters that play vital roles in the DNS framework, they each serve distinct functions and occupy separate positions within the progression of a DNS inquiry. To draw a comparison, you can visualize the recursive resolver situated at the commencement of a DNS query, whereas the authoritative nameserver is positioned at the conclusion of the process.

Reiterative DNS Resolver:

The reiterative resolver stands as the machine that answers a reiterative inquiry from a user and invests the effort to locate the DNS record. It accomplishes this by initiating a sequence of queries until it connects with the authorized DNS nameserver holding the requested record (or ceases and produces an error if no record is located). Fortunately, reiterative DNS resolvers are not always obliged to conduct numerous requests to trace the essential records for replying to a user; caching, a data persistence procedure, aids in expediting the essential queries by delivering the requested resource record earlier in the DNS search process.

Authoritative DNS Server

In simple terms, an authoritative DNS server is a server that possesses and bears the responsibility for DNS resource records. Positioned at the base of the DNS lookup hierarchy, this server is the one that furnishes the requested resource record. In doing so, it enables the web browser initiating the inquiry to locate the essential IP address required for reaching a website or other online content. The authoritative nameserver has the capacity to fulfill queries using its own stored data, eliminating the need to consult other origins, since it stands as the ultimate, definitive source for specific DNS records.

It’s important to note that in cases where the query is for a subdomain, such as foo.example.com or blog.toffs.com, an extra nameserver will be included in the sequence following the authoritative nameserver. This additional nameserver is responsible for maintaining the CNAME record of the subdomain.

What are the stages involved in a DNS lookup?

In most scenarios, DNS primarily focuses on converting a domain name into the corresponding IP address. To grasp the mechanics of this procedure, it’s beneficial to trace the journey of a DNS lookup from a web browser through the lookup process and back. Let’s delve into the sequence of actions.

Note: Frequently, DNS lookup data is stored in cache either locally within the querying computer or in the remote DNS infrastructure. A typical DNS lookup encompasses 8 stages. When DNS data is cached, certain steps in the lookup process are bypassed, resulting in faster performance. The example below delineates all 8 steps in cases where no caching is in effect.

The 8 steps involved in a DNS lookup process:

  1. A user enters ‘example.com’ in a web browser, and the query travels through the Internet to reach a DNS recursive resolver.
  2. The resolver then sends a query to a DNS root nameserver (.).
  3. The root server responds by providing the address of a Top Level Domain (TLD) DNS server (like .com or .net) responsible for storing domain information. In this case, the request is directed to the .com TLD as we are looking for example.com.
  4. The resolver proceeds to request information from the .com TLD server.
  5. The .com TLD server replies with the IP address of the domain’s nameserver, example.com.
  6. The recursive resolver sends a query to the nameserver of the domain, example.com.
  7. The nameserver responds by providing the IP address associated with example.com.
  8. The DNS resolver then informs the web browser about the IP address of the initially requested domain, example.com.

Upon obtaining the IP address for example.com through these 8 steps, the web browser can proceed with the following actions:

  1. The browser generates an HTTP request directed at the obtained IP address.
  2. The server located at the provided IP address sends back the webpage content to be displayed in the browser (as indicated in step 10).

What exactly is a DNS resolver?

A DNS resolver serves as the primary point of entry in the DNS lookup process, taking care of interactions with the initiating client. It initiates a series of queries that eventually result in the translation of a URL into the essential IP address.

Please take note: A standard uncached DNS lookup entails both recursive and iterative queries.

It’s crucial to distinguish between a recursive DNS query and a recursive DNS resolver. The query denotes the request directed at a DNS resolver, seeking resolution for the query itself. On the other hand, a DNS recursive resolver is the computer that accepts a recursive query and processes the ensuing response by making requisite requests.

What are the various types of DNS queries?

During a standard DNS lookup, three distinct query types come into play. By employing a blend of these query types, an optimized approach to DNS resolution can be achieved, leading to reduced distance traveled. Under ideal circumstances, cached record data will be accessible, allowing a DNS name server to furnish a non-recursive query.

The three types of DNS queries are as follows:

  • Recursive query - In a recursive query scenario, a DNS client necessitates that a DNS server (usually a DNS recursive resolver) responds to the client with either the requested resource record or an error message if the resolver cannot locate the record.

  • Iterative query - Within this context, the DNS client permits a DNS server to offer the best available answer. If the queried DNS server lacks a match for the query name, it provides a referral to a DNS server with authority over a lower level of the domain namespace. Subsequently, the DNS client generates a query to the referred address. This cycle continues with successive DNS servers along the query chain until an error or timeout transpires.

  • Non-recursive query - This type of query generally arises when a DNS resolver client questions a DNS server for a record that it can access, either due to its authoritative status for the record or the presence of the record within its cache. Typically, DNS servers cache DNS records to curtail additional bandwidth consumption and alleviate the load on upstream servers.

What exactly is DNS caching, and where does it take place?

The purpose of caching is to temporarily store data in a strategic location to enhance performance and reliability when requesting data. DNS caching involves storing data closer to the client making the request. This helps resolve DNS queries faster and reduces the need for additional queries down the DNS lookup chain. This ultimately improves loading times and minimizes the consumption of bandwidth and CPU resources. DNS information is cached in various locations, each of which retains DNS records for a specific duration as determined by a parameter called time-to-live (TTL).

Browser DNS Caching

Modern web browsers are designed to cache DNS records for a predefined duration. The rationale behind this approach is clear: when DNS caching takes place nearer to the web browser, fewer steps are needed to check the cache and send correct requests to an IP address. When a DNS record is requested, the browser’s cache is the initial location where the sought-after record is checked.

For those using Chrome, you can monitor your DNS cache status by visiting chrome://net-internals/#dns.

Operating System (OS) Level DNS Caching

The DNS resolver at the operating system level is the last stop within your local environment before a DNS query leaves your device. This resolver, often referred to as a “stub resolver” or DNS client, handles the query process within your operating system. When an application sends a request to a stub resolver, the resolver initially checks its own cache for the requested record. If the record is not found, the resolver then sends a DNS query (with a recursive flag activated) outside the local network to a DNS recursive resolver operated by the Internet service provider (ISP).

Upon receiving a DNS query, the ISP’s recursive resolver performs a similar check. Like the previous steps, it verifies whether the requested host-to-IP-address translation is already stored in its local persistence layer.

The recursive resolver also offers additional functionality based on the types of records present in its cache:

  1. If the resolver lacks A records but possesses NS records for the authoritative nameservers, it will directly query those name servers. This bypasses several steps in the DNS query process, preventing the need to consult root and .com nameservers (in the case of searching for example.com) and expediting the resolution of the DNS query.

  2. If the resolver lacks NS records, it queries the Top-Level Domain (TLD) servers (.com in our example), skipping the root server.

  3. In rare instances where the resolver lacks records pointing to the TLD servers, it then queries the root servers. This situation usually arises after a DNS cache has been cleared.