Enindu Alahapperuma
Software Engineer
Sri Lanka
I'm a back-end engineer, system administrator, and website security expert.
Most developers have a high-level understanding of DNS. However, for web developers, grasping DNS at a low level is crucial. Writing yet another article explaining DNS from a high-level perspective would be redundant. Instead, this article delves into the DNS protocol and its inner workings at a low level, offering a system administrator's perspective. Let's dive in.
First off, assuming you're familiar with the OSI model, DNS operates as an application-layer protocol. It allows systems to translate domain names into IP addresses, eliminating the need to memorize IP addresses manually. As a critical component of web infrastructure, DNS is something every web developer should understand, along with fundamental HTTP concepts. While it's not mandatory for the average web developer, having a solid grasp of how DNS works can be highly beneficial. Here's a simplified explanation of its operation.
First, it's important to understand that there are four types of DNS servers. I won't go into detail about each one here, but you'll get a basic understanding of them as we progress through this article.
DNS resolution involves several steps that we need to examine.
When you visit a website using its domain name from an HTTP client, your operating system's local DNS resolver first attempts to resolve the IP address using the OS cache. Don't confuse the local DNS resolver with a recursive resolver—it's not a DNS server, just a resolver. Every general-purpose operating system has their own built-in DNS resolver. If it finds the IP address in the cache, it sends it directly to the HTTP client, allowing the client to immediately initiate a connection with that IP address.
If your local DNS resolver can't find the IP address in the cache, it generates a DNS request (Also known as a DNS query, though I prefer the term "DNS request") and forwards it to your local network. Most local networks have a recursive resolver, which is a DNS server. If no recursive resolver exists in your network, your ISP may use an external one, such as Google's DNS (8.8.8.8) or Cloudflare's DNS (1.1.1.1). A recursive resolver acts as an aggregator or distributor. It first checks its own cache for the IP address. If found, it sends a DNS response to the local resolver. The local resolver will likely cache the IP address to save bandwidth the next time you visit the same domain. Finally, the IP address is sent to the HTTP client, which then initiates a connection with the server.
If the recursive resolver doesn't have the IP address in its cache, it forwards the DNS request to the root servers. While root servers don't store IP addresses themselves, they serve as the top of the DNS hierarchy. They contain information to help locate the appropriate TLD (Top-Level Domain) servers. The root server will then send a DNS response to the recursive resolver, directing it to the relevant TLD server.
Let me briefly explain the DNS hierarchy. The DNS hierarchy is a tree-like structure organized into different levels, with each level having a specific responsibility. Here's the structure from top to bottom:
Next, the recursive resolver forwards the DNS request to the TLD server. While TLD servers don't store IP addresses either, they have information about authoritative name servers, which hold the original DNS records (Also known as resource records) such as A, AAAA, CNAME, TXT, MX, etc. Typically, A and AAAA records store the IP addresses for the domain. The TLD server then sends a DNS response back to the recursive resolver, directing it to the appropriate authoritative name server.
If you've been following the article so far, you might have an important question: TLD servers are responsible for storing DNS records for top-level domains, so what happens if you try to visit a second-level domain like .edu.lk? Well, second-level domains require an extra step in the DNS resolution process. When you visit a second-level domain, the TLD server will respond with the respective authoritative server to the SLD. This means the recursive resolver may need to send an additional DNS request to the relevant authoritative server of the SLD to continue the DNS resolution. This extra step explains why SLDs are often cheaper.
Once the recursive resolver receives the authoritative name server, it forwards the DNS request to that server. The authoritative name server will then respond with the correct IP address, which the recursive resolver caches for future use. The recursive resolver then sends the DNS response back to the local resolver. The local resolver also caches the IP address to save bandwidth and time, before passing it to the HTTP client. Finally, the HTTP client can begin establishing a connection with the provided IP address.
Now, you might have another question: what if the domain has a subdomain? In this case, the DNS resolution process might require an extra step, especially for deeply nested subdomains. When you visit a subdomain, there are two possible scenarios that can occur during the authoritative name server step.
Reading this, it might seem like a complex process. However, in reality, the entire DNS resolution process is completed in milliseconds. In most cases, you don't even reach the authoritative name server part. The local DNS resolver typically handles the lookup, and in some cases, the process only involves the recursive resolver without going any further.
So, this is how DNS works from a low-level perspective.
I mentioned DNS requests and responses above. Now, let's compare DNS with another application-level protocol, HTTP. DNS is similar to HTTP but with some key differences. While HTTP follows the Hypertext Transfer Protocol, DNS follows the Domain Name Service protocol. Additionally, HTTP uses TCP to transport data, whereas DNS uses both TCP and UDP depending on the use case. UDP is typically used for most DNS queries due to its efficiency and low overhead. However, TCP is required for longer responses, such as DNSSEC, which exceed 512 bytes, as well as for specific operations like zone transfers.
Both protocols have distinct messaging formats. I explained the HTTP messaging format in a previous article. In reality, DNS requests and responses are sent in binary. They share a similar structure, though they differ in specific details. Here's how a DNS request is structured.
The main difference is that the DNS response includes an additional field called "answer data". Here's the structure of a DNS response.
I'm not going to explain every field in this structure in detail, but there is something worth mentioning. In DNS requests, the "Answer RRs", "Authority RRs", and "Additional RRs" fields are always null because they store information about DNS records. These fields get populated when DNS responses are sent.
Now that you're familiar with the DNS message structure, I won't go into DNS records in detail since most web developers are already familiar with them. Instead, let's focus on the structure of a DNS record.
How a DNS server stores data depends on the DNS server software. As a web developer, you typically don't need to worry about this, but it's useful to understand. Some DNS software, like BIND, stores records in zone files, which are simple text files. Other implementations use different storage methods, such as key-value databases like Redis and RocksDB or relational databases like MySQL and PostgreSQL.
At this stage, you have a fundamental understanding of how a low-level DNS server operates. With that, I conclude this article.