What is DNS? How does it work?

What is DNS?#

DNS, short for Domain Name System, is the domain name system.

The Role of DNS#

The role of DNS is to convert domain names into IP addresses.

The Significance of DNS#

The role of DNS is to convert domain names into IP addresses, allowing people to remember meaningful domain names instead of complex numbers.

How Does DNS Work?#

We can simply think of the DNS workflow as: a librarian searching for a book in a large library.

Four Servers Involved in Web Page Loading#

DNS Recursive Resolver

Role: The librarian
A DNS recursive resolver is a type of server/computer that receives queries from client computers through applications like web browsers. The resolver is generally responsible for issuing other requests to satisfy the client's DNS queries.

Root Nameserver

Role: An index pointing to different bookshelves
The root nameserver is the first step in converting hostnames into IP addresses.

TLD Nameserver

Role: A specific bookshelf in the library
The server hosts the last part of the hostname (for example, in example.com, the TLD server is "com").

Authoritative Nameserver

Role: A dictionary on the bookshelf
The authoritative nameserver is the last stop in the domain server query. If the authoritative nameserver can access the requested record, it will return the IP address of the requested hostname to the DNS resolver (the librarian) that made the initial request.

Steps of DNS Lookup#

DNS Query Process

The DNS query process:

The user types “example.com” in the web browser, and the query is transmitted to the Internet and received by the DNS recursive resolver.
The resolver then queries the DNS root nameserver (.).
The root server responds to the resolver with the address of the top-level domain (TLD) DNS server that stores its domain information (e.g., .com or .net). When searching for example.com, our request points to the .com TLD.
The resolver makes a request to the .com TLD.
The TLD server then responds with the IP address of the domain's nameserver example.com.
The recursive resolver sends the query to the domain's nameserver.
The nameserver returns the IP address of example.com to the resolver.
The DNS resolver then responds to the web browser with the IP address of the initially requested domain. (At this point, the browser has obtained the IP.)
The browser makes an HTTP request to that IP address.
The server at that IP returns the webpage that will be rendered in the browser.

What Types of DNS Queries Are There?#

Recursive Query

In a recursive query, the client requests the DNS server (usually the DNS recursive resolver) to respond with the requested resource record, or return an error message if the resolver cannot find the record.
Iterative Query

The DNS client allows the DNS server to return the best answer it can provide. If the queried DNS server does not match the query name, the server will return a reference to a DNS server that is authoritative for a lower-level domain space. The DNS client will then query the referenced address. This process continues with other DNS servers in the query chain until an error or timeout occurs.
Non-Recursive Query

This query is typically made when the DNS resolver client queries the DNS server for records it has authority over, or if the record exists in its cache. DNS servers usually cache DNS records to prevent further bandwidth consumption and load on upstream servers.

What is DNS Cache, Where is it Stored, What is its Purpose, and How Does Caching Work?#

The purpose of caching is to temporarily store data in a location so that in subsequent responses, the data stored in that location can be returned directly. DNS caching stores data closer to the requesting client to resolve DNS queries more quickly and avoid further additional queries in the DNS lookup chain, thus speeding up and shortening loading times.

DNS data can be cached in different locations, and the validity period of the stored data at each location is determined by TTL (Time to Live).

Browser DNS Cache#

Modern web browsers are designed to cache DNS records for a period of time by default. The purpose is clear; the closer the DNS cache is to the web browser, the fewer processing steps are required to check the cache and make the correct request to the IP address. When a request for a DNS record is made, the browser cache is the first place checked for the requested record.

Operating System DNS Cache#

The operating system-level DNS resolver is the second stop before the DNS query leaves your computer and the last stop locally. The process designed to handle this query within the operating system is often referred to as a “stub resolver” or DNS client. When the stub resolver receives a request from an application, it first checks its own cache to see if the record exists. If not, it sends a DNS query (with the recursive flag set) to the DNS recursive resolver within the Internet Service Provider (ISP).

When the recursive resolver within the ISP receives the DNS query, it will also check whether the requested hostname to IP address conversion has already been stored in the ISP's local persistence layer.

Hosts File#

Local hosts file

How Caching Works#

The DNS resolver will save the response to the IP address query for a certain period. This way, the resolver can respond more quickly to future queries without having to communicate with many servers involved in a typical DNS resolution process. As long as the specified Time to Live (TTL) allows, the DNS resolver will keep the response in its cache.

No Cache:

With Cache:

What is a DNS A Record?#

Address Record. Indicates the IP of the domain.

“A” stands for “Address,” which is the most basic type of DNS record that indicates the IP address of a given domain. For example, pulling the DNS record for [cloudflare.com](http://cloudflare.com) returns the IP address: 104.17.210.9.

“AAAA” stands for IPv6 address.

When to Use DNS A Records#

The most common use of A records is for IP address lookups, matching domain names with IPv4 addresses.

What is an MX Record?#

Mail Exchanger. Helps route the emails to the relevant server.

DNS “Mail Exchange” (MX) records direct emails to mail servers. MX records indicate how to route emails based on the Simple Mail Transfer Protocol (SMTP), the standard protocol for all emails. Similar to CNAME records, MX records must always point to another domain.

Mail Transfer Agent (MTA) software is responsible for querying MX records. When a user sends an email, the MTA sends a DNS query to determine the mail server for the email recipient. The MTA establishes an SMTP connection with these mail servers, starting with the highest priority domain (in the first example above, that would be mailhost1).

What is an NS Record?#

Name Server Record. Indicates the authoritative servers.

NS stands for “Name Server,” and the name server record indicates which DNS server is authoritative for that domain (i.e., which server contains the actual DNS records). Essentially, NS records tell the Internet where to find the domain's IP address. A domain typically has multiple NS records that indicate the primary and secondary name servers for that domain. Without correctly configured NS records, users will be unable to load the website or application.

What is a CNAME Record?#

Canonical Name. Points a domain or subdomain to another domain.

A “Canonical Name” (CNAME) record is used when a domain name or subdomain is an alias for another domain name, instead of an A record. All CNAME records must point to a domain, not an IP address. Imagine a treasure hunt where each clue points to another clue, and the final clue points to the treasure. A domain with a CNAME record is like a clue that can direct you to another clue (another domain with a CNAME record) or the treasure (a domain with an A record).

For example, suppose the CNAME record for blog.example.com has the value “example.com” (without “blog”). This means that when the DNS server clicks on the DNS record for blog.example.com, it actually triggers another DNS lookup for example.com and returns the IP address of example.com through its A record. In this case, we would say that example.com is the canonical name (or true name) of blog.example.com.

A common misconception is that CNAME records must always resolve to the website where the domain they point to is located, but this is not the case. CNAME records simply direct the client to the same IP address as the root domain. After the client accesses that IP address, the web server will still process the URL accordingly. For example, blog.example.com may have a CNAME pointing to example.com, directing the client to the IP address of example.com. However, when the client actually connects to that IP address, the web server will look at the URL, see that it is blog.example.com, and serve the blog page instead of the homepage. (The same IP, the web server displays content based on routing.)

What is a Domain Name?#

A domain name is a text string that maps to a numerical IP address, which can be used to access a website from client software. In simple terms, a domain name is the text that users type in the browser window to access a specific website. For example, Google's domain name is “google.com.”

What Are the Components of a Domain Name?#

Domain names are typically divided into two or three parts, with each part separated by a dot. Reading from right to left, the identifiers in a domain name range from the broadest to the most specific. The part to the right of the last dot in the domain name is the Top-Level Domain (TLD). This includes “generic” TLDs like “.com,” “.net,” and “.org,” as well as country-specific TLDs like “.uk” and “.jp.”

To the left of the TLD is the Second-Level Domain (2LD), and if there is anything to the left of the 2LD, it is called the Third-Level Domain (3LD). Let's look at an example:

For Google's U.S. domain, “google.com”:

“.com” is the TLD (the broadest)
“google” is the 2LD (the most specific)

What is the Difference Between a Domain Name and a URL?#

A Uniform Resource Locator (URL), sometimes referred to as a web address, contains the domain name of the site along with other information such as the transfer protocol and path. For example, in https://cloudflare.com/learning/, “cloudflare.com” is the domain name, while “https” is the protocol, and “/learning/” is the path to a specific page on the website.

What Attacks Involve DNS?#

DNS Spoofing/Cache Poisoning

This is an attack that injects forged DNS data into the DNS resolver's cache, causing the resolver to return an incorrect IP address for a domain. Traffic may be redirected to malicious computers or anywhere else the attacker desires instead of the correct website.

For example, a graduating class of students played a prank by swapping all the classroom numbers on their campus, causing new students who were unfamiliar with the layout to get lost and end up in the wrong classrooms the next day. Now imagine mismatched classroom numbers (records) in the campus directory, with students continually going to the wrong classrooms until someone finally notices and corrects the directory.

Because DNS resolvers typically cannot verify the data in their caches, incorrect DNS information remains in the cache until the Time to Live (TTL) expires or it is manually removed. Many vulnerabilities can lead to DNS poisoning, but the main issue is that DNS was built for a much smaller Internet and is based on a trust model (very similar to BGP). A more secure DNS protocol called DNSSEC aims to address some of these issues but has not yet been widely adopted.

DNS Tunneling

This attack establishes a tunnel through DNS queries and responses using other protocols. Attackers can use SSH, TCP or HTTP to pass malware or stolen information into DNS queries without being detected by most firewalls.

DNS Hijacking

In DNS hijacking, attackers redirect queries to other domain name servers. This can be accomplished through malware or unauthorized modifications to DNS servers. Although the outcome is similar to that of DNS spoofing, it is a distinctly different attack because its target is the DNS records on the domain name server, rather than the cache of the resolver.

How to Poison DNS Cache#

Attackers can poison DNS cache by impersonating a DNS domain server, sending requests to the DNS resolver, and then forging replies when the DNS resolver queries the domain name server, causing DNS cache poisoning. This is possible because DNS servers use UDP instead of TCP, and currently, there is no verification of DNS information.

Why is it Easy for Attackers to Forge Requests and Responses?

DNS requests and responses use the UDP protocol instead of TCP, making UDP easy to forge – attackers can send messages via UDP and fake header data to pretend that the response is from a legitimate server.

If the DNS resolver receives a forged response, it will accept and cache the data indiscriminately, as it cannot verify whether the information is correct and from a legitimate source (UDP is one-way).

Poisoned DNS Cache

The Role of TTL#

The setting of TTL affects updates. For example, when TTL is set to 30 seconds, the second DNS query request will expire, and the cache will expire, receiving the latest version. If TTL is set to 300000 seconds, even if the DNS resolution records are changed, the modifications cannot be obtained immediately; one must wait for the DNS cache to expire.

Create two DNS resolutions, with the same domain pointing to different IPs.

When we access this domain, it triggers a DNS query request, at which point the DNS resolver finds two matching records. It will decide in which order to return them, possibly in one of the following ways:

Return the records in the same order they were received.
Change the order with each request.
Randomly select an order.
Something else.

References#

What is DNS_DNS How It Works

DNS in One Picture (roadmap.sh)

What is DNS Poisoning and DNS Spoofing

What is a Domain Name? - Learn web development | MDN (mozilla.org)