What is DNS and how it works in 2021

What is DNS?

What is DNS and how it works The Domain Name System (DNS) is the Internet’s phonebook. Domain names, such as nytimes.com or espn.com, are used by humans to access information online. Web browsers communicate via Internet Protocol (IP) addresses. Domain Name System DNS converts domain names to IP addresses so that browsers can access Internet resources.

Each Internet-connected device has a unique IP address that other machines can use to locate the device.Domain Name System DNS protocol servers eliminate the requirement for humans to remember IP addresses like 192.168.1.1 (in IPv4) or more complex modern alphanumeric IP addresses like 2400:cb00:2048:1::c629:d7a2 (in IPv6).

What is DNS and how it works?

Domain Name System DNS resolution is the process of translating a hostname (such as www.example.com) into a computer-friendly IP address (such as 192.168.1.1). Each device on the Internet is assigned an IP address, and that address is required to locate the relevant Internet device, much as a street address is used to locate a certain residence. When a user requests a webpage, a translation must take place between what the user types into their web browser (example.com) and the machine-friendly address required to access the example.com webpage.

To comprehend the process of Domain Name System DNS resolution, it is necessary to first learn about the various hardware components that a DNS query must transit through. Apart from the initial request, the DNS protocol lookup occurs “behind the scenes” in the web browser and requires no input from the user’s computer.

When a webpage is loaded, four DNS servers are involved:

• DNS recursor – Consider the recursor to be a librarian who is instructed to go find a specific book somewhere in a library. A Domain Name System DNS recursor is a server that accepts inquiries from client machines via applications such as web browsers. The recursor is then typically in charge of making additional requests in order to satisfy the client’s DNS query.
• The root nameserver is the first stage in converting (resolving) human-readable host names into IP addresses. It can be compared to an index in a library that points to various book racks – normally, it acts as a reference to other more particular locations.
• TLD nameserver – Think of a top level domain server (TLD) as a specific rack of books in a library. This nameserver is the following step in the search for a certain IP address, and it hosts the final portion of a hostname (the TLD server in example.com is “com”).
• Authoritative nameserver – Think of this final nameserver as a dictionary on a book rack, where a specific name can be translated into its definition. The last stop in the nameserver query is the authoritative nameserver. If the authoritative name server has access to the requested record, it will return the IP address for the requested hostname to the Domain Name System DNS Recursor (the librarian) who initiated the request.

What is the distinction between a recursive DNS resolver and an authoritative DNS server?

Both notions refer to servers (or groups of servers) that are part of the DNS configuration for website DNS infrastructure, but each serves a different purpose and dwells in separate parts of the DNS query pipeline. One way to think about it is that the recursive resolver is at the start of the DNS query, while the authoritative nameserver is at the finish.

DNS recursive resolver

The recursive resolver is the machine that responds to a client’s recursive request by searching for the DNS record.
It accomplishes this by a series of requests until it reaches the authoritative DNS nameserver for the requested record (or times out or returns an error if no record is found). Fortunately, recursive DNS resolvers do not always need to make several queries to find the records required to respond to a client; caching is a data persistence mechanism that helps short-circuit the necessary requests by supplying the requested resource record earlier in the DNS lookup.

DNS server with authority

Simply said, an authoritative DNS server is a server that stores and manages DNS resource records. This is the server at the end of the DNS lookup chain that will return the requested resource record, allowing the web browser performing the request to reach the IP address required to access a website or other web resources.
Because it is the last source of truth for specific DNS records, an authoritative nameserver can satisfy queries from its own data without needing to query another source.

 

It is worth noting that if the query is for a subdomain, such as foo.example.com or blog.cloudflare.com, an additional nameserver will be added to the sequence following the authoritative nameserver, which is in charge of holding the subdomain’s CNAME record.

There is a significant difference between many DNS services and the one provided by Cloudflare. DNS configuration for website DNS recursive resolvers such as Google DNS, OpenDNS, and service providers such as Comcast all have data center deployments of DNS configuration for website DNS recursive resolvers. These resolvers enable speedy and straightforward requests via optimized clusters of DNS-optimized computer systems, but they are fundamentally different from Cloudflare’s nameservers.

Cloudflare manages infrastructure-level nameservers that are critical to the Internet’s operation. One prominent example is the f-root server network, for which Cloudflare is partially responsible. The F-root is a component of the root level DNS nameserver infrastructure that handles billions of Internet queries per day. Our Anycast network enables us to manage enormous volumes of DNS configuration for website DNS traffic without disrupting service.

What steps are involved in a DNS lookup?

In most cases, DNS is concerned with translating a domain name into the proper IP address. To understand how this process works, trace the course of a DNS lookup from a web browser to the DNS lookup process and back again. Let’s go over the steps one by one.

It is important to note that DNS configuration for website DNS lookup information is frequently cached, either locally on the querying computer or remotely in the DNS infrastructure. A DNS lookup typically consists of eight phases. When DNS configuration for website DNS information is cached, steps in the DNS lookup process are bypassed, making it faster. The following example shows all 8 phases when no cache is present.

The eight steps of a DNS lookup are as follows:

1. When a user enters ‘example.com’ into a web browser, the query is routed over the Internet and received by a DNS recursive resolver.
2. After that, the resolver queries a DNS root nameserver (.).
3. The root server then responds to the resolver by providing the address of a Top Level Domain (TLD) DNS server (such as.com or.net), which holds information for its domains. When we search for example.com, we are directed to the.com TLD.
4. After that, the resolver sends a request to the.com TLD.
5. Following that, the TLD server answers with the IP address of the domain’s nameserver, example.com.
6. Finally, the recursive resolver queries the domain’s nameserver.
7. The nameserver then returns the IP address for example.com to the resolver.
8. The DNS resolver then returns to the web browser the IP address of the domain that was originally requested.

Once the DNS configuration for website lookup’s eight steps have produced the IP address for example.com, the browser can make the following web page request:

1. A HTTP request is sent to the IP address by the browser.
2. The server at that IP address returns the webpage to the browser (step 10).

What exactly is a DNS resolver?

The DNS resolver is the first stage in the DNS lookup process, and it is in charge of dealing with the client who initiated the request. The resolver initiates a series of requests that eventually results in a URL being translated into the required IP address.

It should be noted that a typical uncached DNS lookup will include both recursive and iterative requests.

It is critical to distinguish between a recursive DNS query and a recursive DNS resolver. The query refers to the request made to a DNS resolver to resolve the query. The computer that accepts a recursive query and processes the response by performing the necessary requests is known as a DNS recursive resolver.

What are the different sorts of DNS Queries?

There are three types of queries that occur in a normal DNS lookup. An efficient DNS resolution procedure can result in a reduction in distance traveled by combining these requests. In an ideal world, cached record data would be available, allowing a DNS name server to respond to a non-recursive query.

There are three types of DNS queries:

1. Recursive query – In a recursive query, a DNS client expects a DNS server (usually a DNS recursive resolver) to respond with either the requested resource record or an error message if the resolver is unable to discover the record.
2. Iterative inquiry – in this case, the DNS client will let the DNS server to offer the best possible result.
   If the queried DNS server does not have a match for the query name, it will forward the query to a DNS server authoritative for a lower level of the domain namespace. After then, the DNS client will query the referral address.
   This operation is repeated with additional DNS servers farther down the query chain until an error or timeout occurs.
3. Non-recursive query – This occurs when a DNS resolver client searches a DNS server for a record that it has access to, either because it is authoritative for the record or because the record resides in its cache.
   A DNS server will typically cache DNS records to save unnecessary bandwidth consumption and pressure on upstream servers.

What is DNS caching? Where does DNS caching take place?

The goal of caching is to temporarily store data in a location that improves data request performance and dependability. DNS caching is storing data closer to the asking client so that the DNS configuration for website query can be resolved sooner and subsequent searches farther down the DNS lookup chain can be avoided, hence improving load times and lowering bandwidth/CPU use. DNS data can be cached in a number of locations, each of which will hold DNS records for a predetermined amount of time indicated by a time-to-live (TTL).

DNS caching in browsers By default, modern web browsers cache DNS records for a certain amount of time. The goal is apparent; the closer DNS caching occurs to the web browser, the fewer processing steps are required to check the cache and make the necessary requests to an IP address. When a DNS record request is performed, the browser cache is the first site searched for the requested record.

You can check the health of your DNS cache in Chrome by navigating to chrome:/net-internals/#dns.

DNS caching at the operating system (OS) level

The DNS resolver at the operating system level is the second and final local stop before a DNS query leaves your machine. A “stub resolver” or DNS client is the process within your operating system that is designed to handle this query. When a stub resolver receives a request from an application, it first examines its own cache to verify if the record is available. If not, it sends a DNS query (with the recursive flag set) outside the local network to a DNS recursive resolver within the Internet service provider (ISP).

When the ISP’s recursive resolver receives a DNS query, it will, like all previous phases, check to determine if the required host-to-IP-address translation is already stored within its local persistence layer.

Depending on the kind of entries in its cache, the recursive resolver provides additional functionality:

1. If the resolver lacks A records but has the NS records for the authoritative nameservers, it will ask those name servers directly, skipping several steps in the DNS query. This shortcut avoids lookups from the root and.com nameservers (in our search for example.com) and speeds up DNS query resolution.
2. If the resolver does not have the NS records, it will query the TLD servers (.com in our case) instead of the root server.
3. If the resolver does not find any records pointing to the TLD servers, it will query the root servers. This usually happens after a DNS cache has been emptied.