Why did the DNS server break up with its girlfriend? It couldn't resolve their issues!
Introduction to DNS
Imagine a situation where you have to remember a long and unique set of numbers for every single website you visit on the internet. It may be possible to remember a few of them, but typing these numbers multiple times a day to locate a website is nearly impossible for the common population. Even a simple, everyday website name like "www.google.com" is easier to remember than the unique IP address (say, 142.250.195.196) associated with it. This behavior is very similar to the fact that memorizing the phone number of a person is difficult, whereas recalling that person’s name is relatively easy.
Does imagining such a situation make surfing the internet quite problematic?
The introduction of DNS makes the exploration of the internet easy and much more fun. It has come a long way from manually mapping the ever-increasing host names and their associated addresses in a centralized text file named HOSTS.TXT to a name-resolver service popularly known as the Domain Name System.
What is DNS
As the name suggests, DNS is a system of naming a myriad of domains available on the internet, i.e., it provides the database that stores the translation of human-readable hostnames such as "www.google.com" to machine-understandable IP (Internet Protocol) addresses such as 142.250.195.196, which the web browsers can use to load web pages. It thus facilitates limitless navigation and countless access to websites and online services, making it a vital component for internet functionality.
How Does DNS Resolution Work
When you are looking up any website by typing in the address or URL in the address bar of a web browser and press enter, the website gets opened on your browser within a few milliseconds. It sounds magical, doesn’t it? But behind this seemingly magical process lies the complex architecture of the Domain Name System (DNS). This architecture involves multiple layers and components working together seamlessly to ensure efficient and reliable website access for users worldwide.
Before learning about the DNS architecture involved in the DNS lookup, let’s take a look at the intricacies of DNS query resolution, step-by-step:
Step 1: A user opens a browser and types a website name in the search bar, triggering a DNS request in the background.
Step 2: As the DNS query is initiated, it is sent to the local DNS cache to check if the IP address of the requested domain is already present in the local repository or not. If yes, then we get a direct cached response to the query request, and it gets forwarded to step 9.
Step 3: When the local DNS cache resolver does not have the IP address of the requested domain name, the query is forwarded to the nearest recursive DNS server, usually provided by the user's ISP (Internet Service Provider). A recursive DNS resolver has its own cache memory; it operates similarly to the local cache. If it has the IP address cached, the query will return directly to the user. If not, the query is forwarded to the next step.
Step 4: The recursive DNS resolver then forwards the request for the domain (say, www.example.com) to the root name server to look for the ".com" TLD extension. The 13 root name servers that contain information about the top-level domain name extensions forward the request to the TLD server for ".com" domains. There are 13 logical root name servers, named A through M. Each logical root name server has a unique IP address. These 13 logical servers form the foundation of the Domain Name System (DNS).
Step 5: The request for resolving www.example.com then gets forwarded to the TLD server for ".com" domains to search for the specific authoritative name server for the www.example.com domain. The query moves to the next step.
Step 6: The request gets directed to the dedicated authoritative name server for the www.example.com domain to fetch its associated unique IP address (say, 93.184.216.34) via the TLD server. The authoritative name server, being the absolute authority on the domain information, then answers the request with the IP address of the requested domain.
Step 7: The returned IP address from the authoritative name server is then recorded in the cache of the recursive DNS resolver for a fixed amount of time, as per the TTL (Time to Live), and the reply of DNS query is forwarded to the requester machine. The purpose of TTL here is to optimize network performance and improve overall efficiency while speeding up the response process and ensuring the information cached is up-to-date.
Step 8: The response to the DNS query from the recursive server is cached in the local DNS cache on the user's machine (as per the caching policy of the OS). This caching helps reduce network latency and improve the user experience in case the same website is requested again by the user.
Step 9: Finally, the browser has the IP address of requested website that the user needs. The browser now sends the HTTP request to the web server at that IP address. The web server returns the web page for www.example.com to be rendered on the web browser.
Architecture of DNS
The DNS system is dependent on its database, which has a structured, distributed, and hierarchical framework. This structure is an organized arrangement of domain servers, from the most specific to the most generic, thus specifying a unique and unambiguous path or location to a particular resource on the internet. This style of defining a hostname is known as FQDN (Fully Qualified Domain Name). Let's take an example of www.example.com and understand the hierarchical breakdown.
DNS Hierarchy
The question we want to answer in this section is:
How does DNS use different parts of FQDN to locate a particular website?
To understand this, it's essential to learn how the four different hardware components of DNS help load a web page. Let's simplify the concept by taking an example of a house address, which typically comprises a house number, street name, city name, and country name.
DNS Recursive Resolver: Assume it to be a GPS that provides a detailed direction and guides a person to reach a specific destination. It is designed to respond to a client query made via applications such as web browsers and return the particular IP address of the requested domain name. It recursively makes a series of requests until it reaches the accurate, authoritative name server.
Root Name Server: The DNS hierarchy starts with a root server similar to a country name in our house address example above. Just like the country represents the largest geographical area, the root server acts in a similar way, being the first step in resolving domain names to a unique IP address. Furthermore, there are 13 root servers worldwide, which provide information about top-level domain (TLD) servers and authoritative name servers.
Top-Level Domain Server: The next block down the DNS hierarchy is the TLD server. It can be a city name within the country. The TLD extensions look like .com, .net, .biz, .org, .info, .edu, or country-based TLD names such as .uk, .nl, .de, .be, .au, .ca, and so on. It directs the query request to relevant authoritative name servers, or Second Level Domains (SLDs).
Authoritative name server: the last block of the DNS hierarchy, which maintains the actual DNS records. It can be thought of as a street address that leads a person to a specific destination. An authoritative name server is designed to hold and maintain detailed records of the requested domain. It is responsible for sending the IP address of the requested domain information back to the requesting recursive DNS server. The domain names are stored in text files on the authoritative name server.
DNS Record Types
DNS records serve as directives stored within Zone Files on DNS servers, providing important information about website names and IP addresses. DNS records help servers find where they need to send internet requests.
Here are some common DNS record types:
A record: An A record (or Address Record) points a domain name to an IP address. It works like a translator, changing domain names into IP addresses.
AAAA Record (Quad A): It operates similarly to A Records but is designed to correspond to an IPv6 address.
CNAME record: A CNAME record forwards a domain name to a different domain name. This record functions as a pointer, directing to another domain or subdomain exclusively, not to an IP address. It maps an FQDN to another FQDN, bringing multiple hosts to a singular location. It's helpful when changing the IP address of that website's use without affecting bookmarks or similar things that users might have saved.
MX record (Mail eXchange): The MX record routes email messages to a specific mail server linked to a domain from a designated mail host on a different server. Thus, helping us identify the mail server responsible for a domain / subdomain.
NS record: The NS, or Name Servers, record denotes which DNS server is authoritative for a domain, which means it identifies which server contains the current records for a domain.
TXT record (TeXT Record): A TXT record is utilized for information and verification purposes. The TXT record shares information about your domain to other servers, such as what services the domain is using. It lets admins add notes that humans and machines can read. They use it for things like email validation, setting rules, and ownership verification, and it doesn't need special rules for writing it.
SOA Record: The SOA record is a resource record that stores information regarding all the DNS records within a given zone.
SRV records: The SRV records establish connections between services and hostnames.
PTR Record: A PTR record (Reverse DNS record) does the opposite of an A record, and it resolves an IP address to a domain name.
DNS Caching
DNS caching is the caching of DNS queries and replies by devices or servers in temporary storage to expedite subsequent lookups. It keeps track of recently visited websites and IP addresses, helping the computer quickly access them when needed again.
The primary purpose of DNS caching is to speed up access to the information in the domain naming system. It's similar to creating a shortcut to quickly retrieve information about where things are located on the internet and saving time by remembering this shorter path to information.
Querying devices can retain IP addresses obtained from DNS queries for a specified time frame. It saves time because the device don't need to look up the address again; it already knows it, like remembering a phone number instead of searching for it every time you want to call someone.
DNS caches can be saved in different spots. Some common ones are:
Web Browser: Before a DNS query leaves the machine to reach a local DNS resolver server, the browser serves as the primary cache. Browsers like Mozilla Firefox, Apple Safari, Google Chrome, etc.
Operating system: Most operating systems have their own built-in DNS resolvers called stub resolvers. These resolvers store DNS information and deal with queries before sending them to an outside server. Usually, after the browser, the operating system is checked for supporting DNS resolution.
Recursive resolver: DNS recursive resolvers can cache the responses to DNS queries. These helpers sometimes have the right information already, so they can make finding things on the internet faster by skipping some steps.
DNS Caching Challenges
While essential for improving network efficiency and reducing latency, DNS caching comes with its challenges. Here are some common challenges associated with DNS caching:
Stale Data
One significant challenge is the potential for stale data in the cache. If changes occur in the IP address of a domain, the cached information may become outdated. This can result in users being directed to the wrong IP address, causing service disruptions, or exposing them to security risks.
TTL (Time to Live) Management
The TTL value associated with DNS records determines how long the resolver should consider the cached data as valid. Managing TTL effectively is crucial. Too short a TTL may lead to frequent queries to authoritative servers, increasing network traffic, while too long a TTL may result in outdated information being retained in the cache.
DNS Propagation Delays
Changes to DNS records might take time to propagate across all servers. Cached information might remain outdated during this period, causing temporary access issues.
DNS Cache Poisoning
Cache poisoning is a security concern where malicious actors attempt to manipulate the cache with incorrect information. By introducing false data into the cache, attackers can redirect users to fraudulent websites, leading to phishing attacks or other malicious activities.
Privacy Concerns
Cached DNS data can potentially reveal users' browsing habits and preferences. Privacy concerns may arise if the cached data is not handled securely or if there are inadequate measures to protect user information stored in the cache.
DNS Spoofing
DNS spoofing involves introducing false DNS records into the DNS resolver’s cache. On successful poisoning of the DNS cache, users can be redirected to malicious websites. Ensuring the integrity of the cached data is essential to preventing DNS spoofing attacks.
Note: DNS cache poisoning is a method of DNS spoofing. DNS cache poisoning is a method that takes advantage of a flaw in the domain name system where an attacker could inject an IP address into the DNS resolver’s cache.
Cache poisoning occurs when the attacker spams made up or forged transaction IDs and ports to the DNS resolver, and if the DNS resolver receives the correct transaction ID and port from the attacker before the legitimate response from the authoritative DNS server arrives. If the resolver accepts the attacker’s response, it will cache the incorrect IP.
DNS Weaknesses and Vulnerabilities
DNS was conceptualized in a world where cybersecurity was not a major concern. As a result of its lack of defense-related design, attackers could use it to steal data, take over websites, launch Denial of Service (DOS) attacks, direct users to malicious websites for phishing, and leak personally identifiable information. One of the major vulnerabilities found in DNS was DNS cache poisoning.
On top of the common challenges mentioned above in DNS caching implementation, some common DNS vulnerabilities are:
DNS Spoofing: When an attacker sends fake information to a victim's computer or network, the victim's system believes these false directions. As a result, the attacker controls the victim's traffic and redirects it to the wrong location. This lets the attacker redirect the traffic, see private information, or launch more attacks.
DNS Hijacking: DNS hijacking, also known as DNS redirection, is a type of attack where DNS queries get resolved incorrectly, leading users to unexpected and potentially harmful websites.
DNS Amplification: DNS amplification is a cyberattack that misuses the Domain Name System (DNS) to flood a target with too much data. It tricks open DNS servers by sending small requests that trigger much larger responses, overwhelming the target's capacity to handle the influx of information.
Zone Transfer Vulnerability: Zone transfer vulnerability refers to a vulnerability that an attacker uses to obtain a complete copy of a DNS zone's data. Attackers can exploit this weakness to get access to sensitive information, such as domain names and IP addresses, stored within a DNS zone.
DNSSEC Attacks: DNSSEC, or Domain Name System Security Extensions, serves as a security protocol by incorporating digital signatures into DNS queries and responses. Its primary objective is to safeguard against DNS spoofing by verifying and securing the authenticity of DNS data. Attacks like key compromise, denial of service, and side-channel attacks are launched against DNSSEC.
References:
https://www.cloudflare.com/en-in/learning/dns/dns-cache-poisoning/
https://www.geeksforgeeks.org/dynamic-host-configuration-protocol-dhcp/
https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-networking-admin/dhcp/dhcp-messages
https://www.techtarget.com/searchnetworking/definition/domain-name-system
Register for instructor-led online courses today!
Check out our free programs!
Contact us with your custom pen testing needs at: info@darkrelay.com or WhatsApp.
Comments