In this post, I’ll go over the basics of DNS so that you’ll be primed and ready for my next post about DNS enumeration. Oftentimes, I feel like DNS doesn’t get the attention it deserves when enumerating services. I mean, it’s a relatively simple protocol. Although it’s simple, there’s a wealth of information that can be learned from it if it’s available—and it most likely will be.
It’s one of the most popular services on the internet as it serves a very fundamental role in how the internet operates. So, let’s talk some DNS!
At it’s most basic definition, Domain Name System (DNS) is responsible for translating an IP (internet protocol) address into a human readable form. This human readable form is called a domain name.
In more practical terms, whenever you type an address (like “duckduckgo.com”) into your browser’s search bar, your browser has to figure out exactly where to retrieve data from your specified site. The address “duckduckgo.com” isn’t actually an address at all—it’s the human readable name that’s useful to us (not the browser). The browser needs a numerical address to the server it wants to request files from. So, it makes a special query to turn that human readable name (domain name) into an IP address.
This process happens every time you type something into a search bar or click a link.
In the early days of the internet, computer users could get away with memorizing a handful of IP addresses to reliably know which servers they are trying to reach. Now, the internet is so vast that it would be impossible to keep track of every IP address. I mean, who would want to type out “126.96.36.199” into their browser every time they wanted to visit google.com?
That’s where DNS comes in—it relieves us of this huge headache by making the internet more human friendly.
Okay, now you know the basics but how does this actually happen?
To understand the magic of DNS, it’s important to understand the most basic query: the recursive query. In a recursive query, four types of DNS servers receive the query along the way. So, we’ll get to learn about these core servers in discussing recursive queries.
They are as follows:
1. Recursive Resolver
This is the first server our DNS query reaches when it is made by the client (the computer that sends the query). The Recursive Resolver is responsible for the initial handling of the request and directing it towards the other servers down the chain.
Think of it as a waiter. You tell the waiter what you want and in a bit they come back with exactly what you ask for (most of the time).
2. Root Nameserver
The next stop for our query is the Root Nameserver. The Root Nameserver takes the domain name we sent in our query and extracts the Top Level Domain.
The Top Level Domain (TLD) is the right most dot-separated part of the query. For example, if I were querying “duckduckgo.com,” it would extract the “com” part of the domain. It then uses this information to direct the query towards yet another server.
In our kitchen analogy, you can think of it as responsible for identifying the side for our order.
3. TLD Nameserver
We’re almost there! Once the query reaches this server, the TLD Nameserver’s job is to match the hostname (the “duckduckgo” part in “duckduckgo.com”) with a server that contains the IP of that domain name.
Back to our kitchen analogy, preparing the side and shipping it off to our head chef to prepare the meal.
4. Authoritative Nameserver
Finally, we made it! This is the last destination of the query. The Authoritative Nameserver contains the record that associates our domain name we requested with the IP address of the server it’s associated with.
Now our browser can reliably communicate with the server to get the files it needs to display the website. Our head chef has finished the meal and has given it back to the waiter for them to serve the client.
It’s important to note that this query could be longer if the domain name contained a subdomain. For example, ftp.example.com might need to query an additional authoritative nameserver for the “ftp” part of the domain after querying the authoritative nameserver for “example.” Thus, the chain would be:
recursive → Root NS → TLD NS → “example” authoritative NS → “ftp” authoritative NS
for a total of five queries instead of just four.
Other Query Types
Usually, a DNS query does not follow this recursive sequence. The query typically follows the recursive sequence only if it has to.
Most often, your computer already has the DNS information you need so it doesn’t have to query the DNS resolver for information. It does this by storing DNS records locally in what is called a cache.
The DNS cache on your local computer is managed by your operating system. Most modern browsers also have their own cache. This saves time, especially for websites you frequently access.
Many DNS resolvers and other name serves also have their own cache which can circumvent the need for additional queries. In other words, DNS cache’s can make queries more efficient by removing the need for additional requests.
Another type of query is the iterative query type. In an iterative query, the resolver or some other name server farther down the chain doesn’t know exactly where to direct you, so it directs you to the server it thinks has the information you need.
Basically, the server gives you a best guess by referring you to another server. This server may or may not have the information you need.
In the event that this query (or any query for that matter) fails, you will receive a timeout error.
DNS is more than simply mapping a hostname to an IPv4 address. There are many types of records nameservers have to keep track of in order to make the web more human friendly.
I’m only going to cover some of the essentials but I highly encourage you to read through them quickly in this article.
Address Mapping (A) Records
A records are the type of records most people associate with DNS. They are responsible for storing the IPv4 address associated with a hostname.
There are also AAAA records that function in the same way as A records, but store IPv6 addresses instead.
Canonical Name (CNAME) Records
CNAME records map hostnames to other hostnames (instead of IP addresses like A(AAA) records do). You can think of these records as creating an alias for hostnames.
This may seem redundant but can be useful if you are hosting multiple domains on the same server. For example, you might have a shared hosting plan where your website is hosted with other people’s website on the same server. Or, you may have a seperate domain for your blog (blog.example.com) that is hosted on the same server you host your main site on (example.com).
Mail Exchange (MX) Records
MX records store IP addresses associated with email domains. An email domain is the name that is on the right side of the “@” symbol in your email address (“gmail.com” for Gmail emails).
When you send or receive emails over the internet, those emails need to know where to go to get routed to the correct recipients. This is handled by a mail server. MX records contain the IP address of the appropriate mail servers for an email domain.
This information is useful to attackers because it increases their attack surface by increasing the number of entry points to an organization in the form of additional servers. The emails themselves can also be used as targets or ways to gleam additional information. So, keep them in mind when doing DNS enumeration.
Name Server (NS) Records
NS records contain the IP address(es) of authoritative nameserver(s) associated with a domain.
An important thing to note is that organizations usually have multiple authoritative nameservers for a layer of redundancy. In the event one nameserver goes down (or gets hacked) the backup can step in and keep everything operational. This can also be useful in the case where maintenance needs to be performed on the primary server (so it has to go down) or for load balancing (distributing traffic between multiple servers).
So, don’t be surprised if you find multiple NS records in a query.
You may have heard the term “DNS Zones” tossed around when referencing DNS. A DNS Zone, is the part of the domain name that is managed by an organization. The levels of organization of DNS zones follow the steps in the recursive query we discussed earlier. So, keep that in mind.
For example, the Root Domain Zone is managed by the Internet Corporation for Assigned Names and Numbers (ICANN). It only contains thirteen servers.
As we move down the levels of DNS from the root, there is also a zone for each type of TLD (.com, .org, .net, etc…).
There are also zones for specific hostnames (example.com). Depending on if a subdomain is hosted on a different server than it’s parent domain, it can have its own DNS zone (blog.example.com on a seperate server than example.com).
You can kind of see a pattern here. Basically, DNS Zones are tightly associated with nameservers. Don’t mistake them for being interchangeable with nameservers, though. Remember, there can be multiple nameservers for redundancy purposes. So, a DNS Zone can have one or more nameservers in it.
A Quick Note on TTL
When enumerating DNS, a record’s TTL may be displayed along with its associated information. TTL stands for Time to Live and is the length of time for which a record is to remain in the cache. This prevents old, less frequently used records from filling up the cache.
TTL is also associated with other levels of the networking protocol stack, so it could have different meanings depending on what protocol you are referring to.
You now know the basics of DNS and can apply this information to DNS enumeration. Be proud of yourself for the knowledge you’ve gained. You’ll now be able to apply it to make your recon more effective.
Of course, if you aren’t confident that this information stuck, I highly encourage you to research on your own. There’s tons of videos and blog posts out there that do a much better job at explaining than me!
In the next article, I’m going to be talking about tools and methodologies hackers use to unveil DNS information. So, you’ll get plenty of chances to explore and practice on your own! 😉